The mini-framework I built used your DICE as the dependency injection. The view receives the models it’s going to use in the constructor
<?php
class HomePageView extends BaseView {
public function __construct( User $users, Article $articles ) {
//.. bind logic here ..
}
So when the controller gets the view from DICE it actually doesn’t need to know the models that are about to be used. If it needs to do a post action it routes the post to the model to do validation (which I consider a model concern, people differ on that) and storage. The controllers doesn’t know much beyond routes and general event sequences - i.e. give the post to this model, then if the model says ok open the results view, otherwise return to the form view with and give it the validation errors the model returned. The controller, not the views, does know if the response is HTML, Ajax or the like and handles final packaging. The view classes handle template management.
To be more specific, views are given SQLviews as ArrayObjects, which may or may not have passed through a universal collator class which is able to take a flat 2 dimensional array and rebuild it into an array of arrays. At that point the array object is simply traversed and filtered as normal. That is, come template time…
<?php foreach( $this->articles as $article):
The SQLview had a filter/find method for the 90% of use cases out there, and though I know I’ll be called a heretic, read queries could be executed on the SQLview for corner cases. Write queries of any sort could not though and any time I found myself wanting to use the same corner case query twice I’d compose a new view object.
It worked reasonably well, but I never really found the time to expand on it.
I was just struggling to work out how you’d reuse the view if, for example, in one place it was showing the results of say a search, and another it was showing the latest entries.