TIP: Use Markdown or, <pre> for multi line code blocks / <code> for inline code.
These forums are read-only and for archival purposes only!
Please join our new forums at discourse.kohanaframework.org
finding tutorials for CRUD (v2 and v3)
  • Hi,

    I am still battling it out with kohana! My problem is now that I have an application which was written in kohana v2. This will not be updated to v3 due to the amount of time involved to do it...but the application is being constantly developed.

    I have to insert a couple of bits of functionality in the frontend and backend which entails CRUD. I can find no information/tutorials/walk-throughs/or example applications which I can use as reference. All the tutorials contains a table which loads data from a database, but these tutorials do not show how to edit and save to the database. Is this too difficult for a beginner to grasp?

    anyway, I´m looking for help regarding how to implement CRUD in the site. I find the quickest way to learn is to carry out a tutorial and look at the docs as I´m doing it. I´m just looking for a basic example which shows the model/controller/view/helper classes which enable CRUD in Kohana 2.

    I´d be very grateful for any help,

    yours,

    Robert

  • can´t delete this!

  • Or let me put this another way....here is the tutorial which I used to get started with kohana 2.3.4

    http://dev.kohanaframework.org/projects/kohana2/wiki/Kohana101?version=29

    I would like to alter the controller and model which sends an email to instead save the data to a db....how would I do this?

  • CRUD is basically routes that do stuff for you. Keep REST in mind, but without using HTTP verbs, but routes. For example

    Route::set('crud', '(< controller >(/< action >(/< id >)(/< method >)))')
      ->defaults(array(
         'controller' => 'index',
         'action' => 'index'
         'method' => 'read'
      ));
    

    in your controller

    class Controller_Index extends Controller{
       function action_index(){
         switch ($this->request->param('method')){
           case 'delete':
             if ($this->request->param('id')){
               /* delete it */
             }
             break;
           case 'update':
             if ($this->request->param('id')){
               /* update it */
             }
             break;
           case 'create':
             /* create it */
             break;
           case 'read':
           default:
             if ($this->request->param('id')){
               /* read the ID */
             } else {
                /* read the list */
             }
             break;
         }
       }
    }
    

    calling site/index/1/update will deal with updating. site/index/create will create a new item, site/index will retrieve all the items, site/index/1 will read item 1, site/index/1/delete will delete ID 1

  • I cant update my post, so just an adjustment:

    Route::set('crud', '(< controller >(/< action >(/< id >)(/< method >)))', array('id' => '[0-9]+', 'method' => '(create|read|update|delete)'))
      ->defaults(array(
         'controller' => 'index',
         'action' => 'index'
         'method' => 'read'
      ));
    

    the regex must be added, so it doesn't get abused, if it's a public url after all

  • This is rather confusing!! I just want to create form which saves data to a database. How does this have anything to do with routing?

  • Routing is essential part of Kohana3. In bootstrap you have to set routes. It may be generic route such as Pocesar wrote for CRUD, but it is not recommended(but I'm using them).

    Here is doc you should read: http://kohanaframework.org/3.0/guide/kohana/upgrading In current version of kohana there are some changes you should learn. At first, passing parameters to action is not allowed as you were used to in Kohana 2.3.x.

    Let's start with this Route

    Route::set('default', '(< controller >(/< action >(/< id >)))')
      ->defaults(array(
         'controller' => 'welcome', 
         'action' => 'index' 
      ));
    

    What will happen

    • http://example.com. It will call in Controller_Welcome method action_index();
    • If you enter http://example.com/contact it will call in Controller_Contact method action_index()
    • http://example.com/user/detail/10 will call in Controller_User method action_detail and within the controller you can access entered id's value by $this->request->param('id');

    Also is strongly recommended to use $this->request->post(); for accessing post data. It is because of the HMVC approach of Kohana3.

  • mmm...so everything is being controlled by URLs. I would like to see how this actually works in a simple example using a controller, view and model. For me it´s such a shame that I can´t learn by doing! I would really love to get the hang of this, but the learning curve is almost vertical!

  • of course you can use one single route and do all the work depending on your form input, the one route to rule them all approach is unmaintainable in the long run. it's also better to create your URLs using Route::get('route name')->uri() then writing by hand. If you need to change the order, the controller or anything else in the route, you'd need to almost manually refactor all your uris

  • I have basically the same route for all admin widgets, where widget is the same name as the table of stuff you want to CRUD.

    Route::set('widget_admin', 'admin/(<controller>(/<action>(/<id>)))')
        ->defaults(array(
            'directory' => 'admin',
            'controller'  => 'widget',
            'action'      => 'index',
    )); 
    

    I have basically the same methods in every admin controller:

    action_index is a paginated list and is the default (as you see defined by the route above) if no other params are found. e.g. yourapp/admin/widget is a list of widgets. Display a status message with Session::get_once( ) if it exists.

    action_edit (admin/widget/edit or admin/widget/edit/23) is used for both adding and editing. If you pass no id (it defaults to 0) then you're adding, otherwise you're editing the object with the passed Request::initial()->param('id'). The edit action is the most complicated, because you have to do your validation and handle postback here. You can instead post to action_insert or action_update accordingly to split it out, but I've stopped using additional methods for that and just handle everything in one edit controller. On failed validation, you post back to the edit page and display errors, otherwise you put a success message in the session and redirect to the list.

    action_remove looks up the item ID passed to display the name and asks the user if they want to delete $widget->name? If you click yes, pass the id over to action_delete via admin/widget/delete/$id (you don't allow direct access here).

    action_delete checks to make sure you just posted from admin/widget/remove, and if so, deletes the widget with ID passed, sets a status message to the session and redirects to the list. You can handle remove with a modal JS dialog from the list page also.

    Occasionally (photo gallery) I'll add a action_reorder method for sorting the list of photos, and for CRUD to manage a huge list of widgets, an action_search displays a custom search form & action_results finds the searched $widgets (reusing the list view).

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

In this Discussion