ExpressionEngine CMS
Open, Free, Amazing

Thread

This is an archived forum and the content is probably no longer relevant, but is provided here for posterity.

The active forums are here.

Number of views

June 13, 2010 4:26pm

Subscribe [3]
  • #1 / Jun 13, 2010 4:26pm

    elmne

    53 posts

    I would like to find out the best approch for an application development.

    What’s the best approach to minimize the number of views that are generated for an application?

    For instance, say that each contoller represents a functionality within the system that requires

    add
    view
    edit
    delete

    Then for each of the above, the following 9 views would be needed

       
    add_info.php
    confirm_added.php - that displays to let user know item is added to the system

    search.php
    view_results.php - for viewing search results

    select_edit.php - for searching item to edit
    edit.php - to display fields to be altered
    confirm_edit.php

    select_delete.php
    confirm_delete.php


    If there are 10 functions in the system, that means a total of 10 functions times 9 views which gives 90 views.

    Ofcourse this becomes unrealistic as the more the application increases in functionality, the greater the number of views.  Yet most of these views display form fields.

    The other option would be to use Codeigniters form helper and create form tags within controllers, so that there are standard views for

    Add
    Confirmation
    View
    Edit
    Confirmation
    Delete
    Confirmation


    However, the problem then becomes almost the same, whereby the contollers become so extensive/long because they are now holding form fields for add/edit/view/delete

    and moreso, formatting output with html becomes a bit restricted, such as embedding fields in a table or <DIV> layout which can then have css applied to it.


    So, what’s the best/recommended way to implement views?

  • #2 / Jun 13, 2010 6:29pm

    steelaz's avatar

    steelaz

    252 posts

    I usually don’t have confirmation pages, when there is a write action (add/edit/delete), after action is completed, I redirect to view (index) page and display flash message with success/error/notice message - http://mrphp.com.au/files/multiple-flash-messages-with-style.jpg

    Generally my controller would have index (view), add, edit, delete methods. Delete method doesn’t have a view. Depending on complexity, it may have separate search method.

  • #3 / Jun 13, 2010 6:55pm

    coolgeek's avatar

    coolgeek

    45 posts

    I don’t know what the best way is to do it.  But I can tell you how I do it.

    My controllers are similar to yours - list/view/add/edit/delete functions.  I have a separate search controller that consolidates the search functionality from several controllers and lets me use common views regardless of what I’m searching on.

    Also note that I write my views as php scripts that echo XHTML, as opposed to XHTML scripts with lots of embedded php fragments.  There is a lot of flow control in my views, so it just seems cleaner to me to do it this way.

    I initially started by writing a single monolithic view per controller, but they got to be unmanageable.  I went back and refactored them following the basic pattern of:

    - form view
    - collection view
    - instance view

    The form view handles add/edit/delete for both posts and comments (separate tables, single model).  The other two views are each mapped to a single purpose function.

    Like steelaz, I use the redirect/flashdata method to signal confirmation, as opposed to redirecting to separate confirmation views.

    So, for my blog, I have:

    application/views/blog/blog_form.php
    application/views/blog/view_blog.php
    application/views/blog/view_post.php

    I did so similarly for forums, groups, events, galleries and messages.

    This is much easier to understand and maintain than the monolithic views (which will become more important when I pass the app off to another developer).  At the same time, writing separate views for the distinct form configurations would result in a lot of repeated code.

    So I’m pretty happy with this structure.

  • #4 / Jun 13, 2010 10:18pm

    elmne

    53 posts

    Thanks for the suggestions

.(JavaScript must be enabled to view this email address)

ExpressionEngine News!

#eecms, #events, #releases