Number of views

#1
[eluser]elmne[/eluser]
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
Quote:
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
[eluser]steelaz[/eluser]
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...-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
[eluser]coolgeek[/eluser]
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
[eluser]elmne[/eluser]
Thanks for the suggestions


Digg   Delicious   Reddit   Facebook   Twitter   StumbleUpon  


  Theme © 2014 iAndrew  
Powered By MyBB, © 2002-2021 MyBB Group.