Designing For The View

Just a tip from someone who’s been there and back: When designing, design for the view. In other words, design the view first. Then work backward to figure out what kind of data the view’s going to need.

I generally lay out the view first, and write whatever code I need to embed in the view. Quite often, the view needs tables of data to present to the user. In this case, along with the overall table design, I prefer to design the arrays which the view will use to capture data from. I record this array structure, and then back up to the model to ensure the arrays get built this way, according to the design. I generally prefer to deliver data to the view in the form of a single array, $data. This array may contain other arrays or any number of other information bits. This data just passes through the page controller without alteration. In other words, the controller takes any input, makes a call to the model to fetch whatever data is needed. I prefer to gather this data in come call to the model class. Whatever method I call will generally return the data I need, and I assign it to the $data array. That array has that data sitting there, ready for the view to use. Shortly, the controller calls the view and the view grabs whatever it needs from the $data array. You don’t have to do it this way, but it makes programming from page to page uniform. Anyone trying to figure out what you did later (including you) will get a firm and quick grasp of your conventions.

Of course, you don’t have to do things this way. But I can’t tell you how many times I’ve designed everything on the front end (model), gotten to the view and realized I was going to have to rejigger the data to simplify things in the view. The result was endless hours having to redo things in the model. Ultimately, had I designed the data for the view in the first place, I would have saved myself a lot of time and effort.

I’m just sayin’…