Designing the Model is equivalent to doing the OO design for all your application business logic. I don’t think there’s a legitimate one-size-fits-all solution.

In “Facts and Fallacies of Software Engineering” Robert L. Glass says,
“Eighty percent of software work is intellectual. A fair amount of it is creative. Little of it is clerical.”

I assert that any framework helps with the part of coding that is clerical. A framework is meant to simplify the repetitive work that really does have common implementation in all apps.

This doesn’t work for the Model, because it’s too hard to make a generalization about what a Model does. Trying to make a general-use framework for Models either sacrifices flexibility that you need, or else results in a framework that retains flexibility, but has usage that is complex that it gives no benefit compared to writing the app directly.

I am very happy with the feedback and have confirmed a bunch of theories I’ve been throwing around in my mind for some time now.

Thank you!

Thank you for chiming in on this subject matter.

Thank you for your feedback which adds to Bill’s recommendation of passing the model object to the view rather than passing the data returned by the model to the view.

This feedback is basically what I was after. Getting responses from those who have more experience than I do on this and confirming certain directions I’m trying to explore.

I feel like you are again are there standing with a flag at the Checkpoint showing me which direction to go as you have been at Zend Nabble forums several months ago giving guidance on why models should not extend Zend_Db_Table.

“why fight KISS?” affirms a few ideas and directions I’ve been thinking of heading at this point in time.

Thanks again. I am eternally grateful!

The first one is to be careful of an absolutist approach. Most of us are guilty of presenting one way of accompishing a task to the exclusion of all else, not always because because we believe it’s the One-True-Way, but because it suits the example we provide. This leads to the fallacy that a View Helper *must* as opposed to *may* look after its own models. In reality, if doing it from a controller is simpler (KISS) without sacrificing both testing capability (testability) and reusability, then there’s not much wrong with it. This is most evident in in-out models – where a View needs a specific Model, but does not itself have much information on WHICH model. Then you have a choice of a) pass the ID, or b) pass the Model itself from a controller. Which is simpler?

The second is what constitutes a model. Like Bill, I’d argue the model provided to a View should be the actual object itself. It costs little (compared to converting to yet another value, not a reference, like an array), offers greater flexibility and the advantage of Model provided methods to the View, and splits the Model View between the View hosted model and its View Helper hosted formatting helpers.

The third, and the one where View Helpers and Models are most likely to be completely warranted, are when the Model is independent of the immediate purpose of the request. This is most obvious in layouts, where the main content is purpose of the request (so its models may come direct from the controller) but it is surrounded by other pieces of markup derived from other models not related to that request. Consider a a blog displaying entries which might also present a summary of comments. The comments are not the purpose of the request (that’s the entries), so the comments are most likely to be derived from a View Helper directly querying a Model it knows about itself. More relevantly, these additional models tend to need nothing (or very little) from the controller.

The key to View Helpers and Models is whether it passes a specific rule, and the rule is simple. Controllers are not Page Controllers. They handle the request at hand, but nothing else if possible. The everything else that’s possible will sit in the View and/or Model leaving the controller thinner, lighter and specific. If its specific nature makes it easier to pass a specific Model to the View directly, well, why fight KISS?

I’ve found that you need model access from your view if you have two-layer caching (model-level and view-level) which is needed if you use the same model for your WS’s and web pages with very complex view logic. The rendering itself takes a time long enough to cache it, but you also need to cache the data on it’s own.

In that particular script I start the code with:
…
$translate = Zend_Registry::get(‘Zend_Translate’);
…
and then ofc it works.

To me the view scrits are meant to be as simple as possible; I’m always trying to keep it as clean of unnecessary code as possible. (I actually struggle when I feel I’m calling something from a view script when there should be a cleaner method of achieving the same goal.)

If I do it like that I can work on the important stuff in the controller, while leaving the more trivial stuff, lik layout and styling to my biorobot co-workers who ar enot as deep in ZF yet as I am.

For this approach passing the variables that are needed from the controller to the view seems somewhat better to me, than exposing the whole object in the view script.

This is something I’ve came across just today, and I feel like its related to your problem, so I’m curious about your opinion:

I’m building a site with I18 support, the layout, views, forms, etc. are all localized.
As I’m using the Translator Bootstrap resource(at this point its undocumented on the ZF site, but its been available for a while, like some other resources /layout for example/), I’ve set up the translator with some nice and clean code.

application.ini:
…
resources.translate.data = APPLICATION_PATH “/translations”
resources.translate.adapter = “Array”
resources.translate.options.scan = “filename”
…

and in the Bootstrap.php:
…
protected function _initTranslator() {
$this->bootstrap(array(‘layout’,'view’));
$translate = $this->bootstrap(‘translate’)->getResource(‘translate’);
$layout = $this->getResource(‘layout’);
$view = $this->getResource(‘view’);
$layout->translate = $translate;
$view->translate = $translate;
return $translate;
}
…

So this way I can access the translator in the layout script and the view scripts as $this->translate and localization works out of the box.

Also the Translator bootstrap resource registers the translator in the Zend_Registry as the Zend_Translate key, so whatever i18 aware component you use in your code it also works.

The only thing that didn’t work like that was a special form, where I use the viewscript form decorator, and it doesn’t inherit things from the view, so the translator is unavailable in that code segment. Its also one of the “not that well documented” parts of ZF. (The element view script decorator has some documentation, but the form version lacks it…I’ve spent a few hours with trial by error method, also browsing through the ZF library code, about what is available for use with it.)

In that particulare script I start the code with:

and then ofc it works.

My problem is that somehow this feels bad…I don’t know why, but I feel uneasy asif I’m doing it wrong. Fetching something from the global registry in a view script.

What do you think?

Maybe this is just a purely academic idea though … not sure if this would offer any *real* productivity gains at the cost of some complexity. The main issue would seem to be where and how to select the context. Probably in a boostrap script or something.

Plus this might complicate issues where one has to work with a designer in the case of html.