Should I be building the options for a select element in the controller or view?

[DeX]

Currently I have a page where a select element resides and it shows a list of all users in the system. Here is my logic for populating the select box:

 

1. That page makes a call to the view to be populated.

2. The view runs a foreach loop and builds a string containing a lot of options elements holding the user names, then returns the long string back to the page to be displayed.

3. The foreach from the view makes a call to the controller to get all the names.

4. The controller passes the request straight through to the model.

5. The model gets all the names from the database, adds them to an array and returns them back to the controller.

6. The controller passes them back to the view.

7. The view iterates through them and builds the list (in step 2 above).

8. Element with all options is displayed on page.

 

I'm confused if the view is for building objects which contain HTML coding, or if the view is the actual webpage being displayed, and the building should be handed off to the controller. Basically I'm wondering if the view should be pages or classes.

[requinix]

Ideally, the controller is in charge of shuffling data between the model and view, and has no knowledge of how the data is stored (model) or how it's presented externally (view). So it should gather together the information that the view will need, and the view should take that data and arrange it into whatever HTML format is necessary.

 

The controller is probably a class and the view is probably a file, but neither of those are actual requirements.

[DeX]

Ideally, the controller is in charge of shuffling data between the model and view, and has no knowledge of how the data is stored (model) or how it's presented externally (view). So it should gather together the information that the view will need, and the view should take that data and arrange it into whatever HTML format is necessary.

 

The controller is probably a class and the view is probably a file, but neither of those are actual requirements.

Does this mean I should just have the foreach loop in the webpage itself and build the option elements right there? This would mean I can avoid having a view class file at all, the view would simply be the webpage.

[Psycho]

 

 

2. The view runs a foreach loop and builds a string containing a lot of options elements holding the user names, then returns the long string back to the page to be displayed.

 

Is the loop creating duplicate select lists of the same data? If so, you should call the process (I assume from a DB) to get the values for the select lists one time. Then, unless each list will have different default values, create the list options one-time. Then populate the list of options in each of the unique select lists. If each select list needs a different default value, then create the lists options independently from the data that was retrieved before the loop.

[DeX]

Is the loop creating duplicate select lists of the same data? If so, you should call the process (I assume from a DB) to get the values for the select lists one time. Then, unless each list will have different default values, create the list options one-time. Then populate the list of options in each of the unique select lists. If each select list needs a different default value, then create the lists options independently from the data that was retrieved before the loop.

At times, yes. Some SELECT elements will be duplicated on more than one screen, like the list of users. That can be used to assign a quote to a salesman or it can be used on the user management screen in the admin section.