I’ve been reading about MVC design for a while now and it seems officially the View calls objects and methods in the Model, builds and outputs a view.
I think this is mainly wrong.
The Controller should act and retrieve/update objects inside the Model, select an appropriate View and pass the information to it so it may display. Only crude and rudiementary PHP variables/simple if statements should appear inside the View.
If the View gets the information it needs to display from the Model, surely there will be a lot of PHP inside the View — completely violating the point of seperating presentation logic.
As with all things programming we need to be pragmatic. A view should only contain presentation logic. That logic can be very simple or can be quite complex. As long as that logic only handles what is displayed on the screen, printed on the report, etc.
What is this information you are passing? Possibly a subset of a model. You could create a new class containing only the information the view should know about or just pass along the model and make sure you only access appropriate data. Anyway, the view should be free to query this passed in model to be able to display a view.
The point of controversy is if you from the view should be able to update the model directly, bypassing the controller. This is where the pragmatic side comes in. I think there are cases that can warrant updating the model directly. Especially if you can use data bindings. The you can assign a text box to a property of the model and let the update automagically happen. If there are a lot of simple property setting this approach can save a bunch of code in the controller. MVC is not a set of rules set in stone. It’s guidelines that when used correctly can produce better code but if used too rigorously can lead to pain and suffering.
Be pragmatic!