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
  • What are your thoughts about CRUD and rest ?, see this pdf for explanation. It's about the seven standard controllers that make Restfull Rails Apps.

    list, show, new, create, edit, update, destroy.

    I have noticed that in the Kohana community there are often only two controllers that take care of handling creating and editing things. But they actually have four responsibilities.

    • 'New' - responsible for showing and empty new form and creating a row. The controller posts to itself
    • 'Edit' - responsible for showing a populated form so you can edit and updating the data. Again the controller posts to itself.

    Having worked a bit with rails this is slightly messy. These responsibilities would be spread out over four controllers. 'New' posts to 'Create', and 'Edit' posts to 'Update'.

    • 'New' - show empty form.
    • 'Create' - handle post from 'New' and try to create a new row
    • 'Edit/id' - show form with data, you always edit something.
    • 'Update/id' - try to update id with post from 'Edit'

    list , show , delete are the same in both worlds.

    Both have some pros and cons.

    Four controller way Pros: The controllers are smaller and with a more specific job to do. Easier to read, Easier to keep DRY. Cons: If a post does not validate, the controller has to redirect back to a different url creating a persistence problem. The app has to remember what the error was in order to display the form with the correct error messages. Usually overcome by simply placing it in a session variable. So we need cookies.

    Two controller way Pros: no need to remember anything if something does not validate. Cons: slightly nasty controller code. Let me show you what i mean. This is a typical Kohana edit controller:

    function edit($id=null)
            // this is an 'edit', show the form with database data
            // this is an 'update' , a submited edit form, validate input then, redirect back to list if valid or show form with $_POST data
            // check for delete
        if (isset($_POST['delete']))
            // tell model to delete row $id
            // Redirect back 
            // ok, it's valid. Tell model to update row $id
            // updating row here
            // Redirect to somewhere after updating
        // this is submitted 'update' that did not validate or a plain 'edit', either way display the form. Forge will add $post data and error message if they exist, thank you Forge!             
       // render html

    Is it just me or is this not nasty?

    I like the 'Rails way' with four simpler controllers. What do you think Hanami should use ?

  • :) funny presentation.

    Yes I don't like many if statements in controllers too, it's not so estetic, it's harder to understand.
    Therefore I choose (and use everyday in my work) 4-controllers way.

    Also it's more flexible, for example in a model may presnt properties, which are set at creation and cannot be changed with edit action.

    About REST using it's a complicated question, I never used PUT or DELETE headers, sending this information by URL, because it's more common practic.
  • Maybe that can be implement in the CRUD_Controller similar to the ORM-Model-Relation, so we don't have to invent create/read/update/delete for every new module. Or we make an CRUD lib, which provides this functionality, which every module/app lib is based on. What do you think?
  • I'm using ORM all the time, I don't have too much time for models. So I've got the CRUD Controller, that has all these methods:
    • list items (basically using my Grid Module)
    • edit (populating the form for editing or creating the entity)
    • save (saving the entity)
    • delete (removing the entity)

    That's pretty much enough for me. These methods are in one CRUD controller, which I extend when I need to use a new entity. The problem is that I need to have CRUD @ back-end, so it would be nice the certain controller extending both Administrative and CRUD. Now I've got to join these two abstract controllers.

    That's pretty much the realization of dyron's idea.
  • So, you're all agreed that CRUD should be a Controller.

    Maybe on xobbs "problems", we'll create a library for easy implementing in controller methods.

    What should CRUD "know". Model name? Class attributes?

Howdy, Stranger!

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

In this Discussion