Extended Views

Friends,

I would enjoy receiving your best practice recommendations for developing a view that contains multiple html selects.

Let's say, I'm developing a user maintenance screen that contains multiple html selects. The data used to populate the selects comes from the database (i.e. departments in a company). The select is used to assign the user to a department.

Here's how I'm thinking of building this view:
1. Develop a main view.
2. Develop a view that generates an html select.
In controller do the following:
1. Obtain data for a select via a model controller.
2. Pass data to view select generator via $data variable.
3. Receive html generated by view and place in an array.
4. Repeat 1-3 as many times as needed.
5. Pass array to main view via $data variable.
6. Main view generates main web page.

This process could be extended and repeated as needed.

Does this seem like a good approach for combining multiple html components generated from dynamic data?

Thanks for the comments.

It seems perfectly sufficient to me, albeit a bit complicated for the example quoted. Could you not just collect the department data through a model call and pass that to the view to generate the select.

It all depends on exactly how the data is to be used and generated, but I would consider writing a helper or library to create the required select data in a more general and reusable way. For instance you may want the departments shown to be dependent on the user role, or training level etc.

Hope that helps,

Paul.

Paul,

Thanks for the feedback.

Making use of a single view that contains all the html seems very reasonable. All the data could be gathered in the controller and then sent to the main view. HTML changes made to the main view wouldn't break other views.

My thought was to use individual views to generate portions of html code (somewhat like a widget). The widgets could then be assembled in the main view. The main reason I decided to use the controller for the heavy lifting is because views can't make use of library code. By doing most of the processing in the controller, I can build code segments in libraries that produce the widgets.

How about other folks? Please comment! Thanks.

Andy

I would say that the select would have to be fairly complicated before I would normally consider something like this, but otherwise I see no reason that it should be problematic to do so. I might even be more inclined to use a helper or closure to generate the select than a separate view, given that the view is likely to be dominated by a foreach loop to generate the option/optgroup elements, but in some environments it may be easier to work with a view.

Bonfire

Practical CodeIgniter 3
CodeIgniter Testing Guide

Since I have to generate multiple html selects in the main and other views, my thought was to do so in a modular fashion.

If the main view contains the code used to generate the html selects, then it couldn't be used by other views.

If helpers are used, then a single function must do all the work since a helper can't call other functions. Not a biggie for html select, but it might cause problems with more robust widgets.

Hence, my thought of generating the html code in the controller and passing it to the main view. But this doesn't seem to follow the MVC paradigm well.

What about using PHP includes in the view?

None of the options seems ideal. Thoughts from the community? Thanks.

Andy

This is generally what leads some people to look for alternatives to MVC. In the end, most of them come down to some sort of three-tier architecture, in which the basic idea is to separate code related to the presentation (View), logic (Controller), and data (Model). Each architecture pattern addresses different levels of separation between the three, primarily centered around whatever environment the pattern was initially created for.

MVC was not created for web applications, but has been widely adopted by web developers, so there are some widely divergent ideas about what goes where in the MVC pattern, and at this point, especially in the PHP world, it's largely based on the framework and the individual development team's preferences.

In a CodeIgniter project, I would generally create a library (or multiple libraries) to handle code like this. In other words, your Controller loads a library to take some data and generate some HTML which you'll then pass to your View for display, or your Controller loads a library which it makes available to your View, and your View passes data to the library to generate HTML which the View will display.

In some cases, the library might be used only by one or two Views, or all of the Views loaded by a certain Controller, or all of the Views which work with data from a certain Model. In other cases, the library might be used by most of the Views in your application.

In your case, though, it may be perfectly acceptable to have more code in a View than may be the case for others. If the code does little more than generate HTML (or some other display format) from some form of input, there's little need for it to exist anywhere other than a View.

I would avoid PHP includes in a view. At that point, you're just abandoning all hope of separation of concerns, as this implies that you know the location of the file to be included, either relative to the current file's location or as an absolute location and that the content of the file is appropriate to be included wherever it is that you've decided to include the file. Even though CodeIgniter doesn't utilize any of the PSRs, I would defer to PSR-1 section 2.3's discussion of what should be included in a given file:

A file SHOULD declare new symbols (classes, functions, constants, etc.) and cause no other side effects, or it SHOULD execute logic with side effects, but SHOULD NOT do both.

Bonfire

Practical CodeIgniter 3
CodeIgniter Testing Guide

mwhitney, Thanks for your thoughtful post.

Your hint about using the Controller to load libraries was very helpful.

With this in mind, and to potentially help others, my strategy is as follows:
1. Use the controller to obtain as much data as possible for the view.
2. Have the controller use models as much as possible.
3. Use database views to support the models. This seems a little more elegant than placing all the SQL code in the php.
4. Pass data (not html) from the controller to the main view.
5. Have the view call upon libraries to generate HTML widgets. Note: these are libraries versus ci views. The main view will pass data received from the controller to the libraries.
6. The main view would compile the HTML widgets together to build the main page.

A couple of observations:
1. Some data will be obtained in the main view (i.e. Ajax data for javascript tables). This is to reduce the size of the browser file since php must 'echo out' data used by javascript in some cases.
2. Not exactly MVC, but it seems to be a consist approach--at least until tomorrow

Comments are very welcome. Thanks.

A couple of observations:
1. Some data will be obtained in the main view (i.e. Ajax data for javascript tables). This is to reduce the size of the browser file since php must 'echo out' data used by javascript in some cases.
2. Not exactly MVC, but it seems to be a consist approach--at least until tomorrow

Comments are very welcome. Thanks.

From the point of view of the web server, an AJAX request for data is just another MVC triad. The controller receives the request from the script, it gets the data from a model, it passes the data to a view. The biggest difference is that many people just output JSON straight from their controller rather than using a view, and the JavaScript in the original view does a little more work to display the data and make additional requests in response to user actions.

In the end (again, from the point of view of the web server), no matter how complicated the JavaScript becomes, it's still just part of the view. You could start creating MVC triads in JavaScript (as a few JavaScript frameworks do), and it would still just be part of the view to CodeIgniter.

Bonfire

Practical CodeIgniter 3
CodeIgniter Testing Guide

i would encourage you to check out the codeigniter form helper and make some mockups. it looks simplistic at first, but its really powerful in terms of being able to keep your views very simple and flexible. So then you can pre-assemble the data for your forms in a model or a library and then pass to the view. Combine that with set_value() from Form Validation for prepopulating form fields with data or showing what the user entered if some part of the form didn't validate.

And you can combine them like

PHP Code:

    $data['weight'] = array(
  'name'        => 'weight',
  'id'        => 'weight',
  'maxlength'   => '5',
  'value' => set_value('weight'),
  'class' => 'form-control',
  'placeholder' => 'pounds',
); 


We can even add css info like 'class' => 'form-control' etc for twitter bootstrap.
$data gets passed to the view. and here is where it really pays off, because this is all we need in the view:

PHP Code:

<?php echo form_input($weight); ?>

Select lists are a little bit more complicated, but you can still pre-assemble the important parts into arrays etc before sending to the view. 

The other angle on this to consider - often when you are making forms, you need to refer to the exact same information like the field names for creating the form validation rules. So if you have one model for assembling the form, and one model for validating it, and those models live close together - makes it much faster to make changes, add new fields, etc. 

and then once you have a pattern and a template you like - you will be able to build complicated forms in a fraction of the time.