> -----Original Message-----
> From: Matthew Weier O'Phinney [mailto:[email protected]]
> Sent: Saturday, March 14, 2009 3:30 PM
>
> -- Vincent de Lau <[email protected]> wrote
> (on Saturday, 14 March 2009, 12:52 PM +0100):
> The mantra of "use view helpers" stems from the fact that in MVC, views
> are allowed to communicate with models in order to fetch content to
> render. The goal, then, is to move all your business logic into models,
> and then write view helpers that access these models (and, optionally,
> format the information for rendering).
First of all, thank you for your answer, I think it clarifies a lot. Maybe
this and parts of the article mentioned earlier should be made into a white
paper or BCP document?
Also, thanks for your patience. I might sound a bit like somebody who just
doesn't want to get it, but I think it is far from that. I want to produce
quality code and systems and I want to learn (and know I have to). I also
want to build something that does what I require.
> As an example, consider this view helper:
>
> class My_View_Helper_RecentEntries extends
> Zend_View_Helper_Abstract
> {
> public $entryTemplate = '<li><a href="%s">%s</a></li>';
>
> public function recentEntries()
> {
> $model = $this->view->entriesModel;
> $recent = $model->fetchRecent();
<snip>
> In this case, we're pulling from a model we've injected into the view,
> and then creating an unordered list which we return. In your view
> script, you then simply echo the results:
>
> <?php echo $this->recentEnties() ?>
And that is where the catch is in my case. I don't want a viewscript to
decide what content to display; I want that to be dynamic. How do I get my
models in the view when I don't know beforehand what helpers are going to be
called and what model access they need? I would argue that that is a
controller task, but you lose that part when using sole helpers.
Part of the problem could be handled by adding a view helper that calls
other helpers (the dynamic part) and passes parameters to them, but I
suppose that doesn't solve the problem of which model to access.
I also find it a problem that for large parts of my system, I would not be
using view scripts for output, making such components harder to reuse. The
current controllers that I'm building, can be used on other sites without
modification. I only need to change my view scripts if required. Some
controllers even made it into our library, leaving only an empty extending
class in the application. (For instance: class ErrorController extends
My_Error_ActionController {} )
> and that's it. This tactic provides better encapsulation, provides
> behavior that is easily testable, and is much more performant as there
> is no need to lookup the controller and dispatch it.
>
> Your suggestion that if performance is an issue with action(), effort
> might go into improving the dispatcher or creating a lightweight
> version
> makes sense in theory... but to do so actually exposes an important
> point: modifying how the dispatch sequence works would actually
> potentially break action().
>
> Ironically, the method of using view helpers instead of action() makes
> it *easier* to replace elements of Zend_Controller with your own
> implementations, as you no longer need to worry that changing the
> implementation will break the functionality.
I totally understand your point and would never suggest to alter the
behavior of the current dispatcher or action(). I specifically mentioned
'secondary' content because it might warrant a far less complex way of
'dispatching'. Wrapping all my earlier comments and experience up, I can see
a helper that can load other 'helpers' or 'mini-controllers'. Those
'helpers' might even use view scripts to control their output.
However, I could also understand that this would part to far from the
(traditional) MVC pattern. That would however get me thinking if MVC is
really the way to do this type of web applications.
Anyway, I would love more input and opinions on the subject.
Kind regards,
Vincent de Lau
[email protected]
