-- Philip G <[EMAIL PROTECTED]> wrote
(on Sunday, 22 June 2008, 11:15 AM -0500):
> Okay, humor me on this one. But this is something I need to understand; why?
>
> Here's my logic: the whole purpose of the MVC pattern is to separate out the
> pieces of code, specifically the presentation logic (view), from the business
> logic (controller). However, Zend_Form and its decorators seem to have taken a
> step back in this, putting presentation logic (decorators) right smack in the
> middle of business logic (form processing).
>
> I have to ask, why?
>
> Does this make sense? If so, can you please explain to me as to why?
>
> I can understand Zend_Form for easy form processing, but quite frankly, I
> rather have a Zend_Form that works for processing, validation and an easily
> method of retrieving the errors, instead of an all-in-one: display,
> processing,
> validation, error display.
>
> Maybe I just don't get decorators? To me, decorators put presentation logic
> smack in the middle of business logic. A step explicitly unfavorable within
> the
> MVC pattern. Am I missing something here?
The point is threefold:
* Avoid duplication of code
* Keep form and business logic in sync
* Make presentation logic simpler
Regarding the first two items, if you have input filter logic in your
model, and then additional logic for presentation, you can quickly go
out-of-sync during early development. Consider a form where you start
adding columns to the database -- you now have to add items to your
input filter _and_ to the view layer (the actual form). This leads to
syncing issues, but also to some duplication of effort.
Regarding point 3, consider the following:
<dt><label for="foo" class="<?= ($element->isRequired()) ?
'required' : 'optional' ?>">Foo?</label></dt>
<dd>
<input type="text" value="<?= $this->escape($element->getValue()) ?>
name="foo" id="foo" />
<? if ($element->hasErrors()): ?>
<ul class="error">
<? foreach ($element->getErrors() as $message): ?>
<li><?= $this->escape($message) ?></li>
<? endforeach ?>
</ul>
<? endif ?>
<? if (null !== ($description = $element->getDescription())): ?>
<p class="desc"><?= $description ?></p>
<? endif ?>
</dd>
Consider doing that for 20 elements. It's painful. Now consider the
decorator system, which allows you to pull and render the bits and
pieces you need and incrementally build up your element. In your model
or controller or form class, you might have this:
$element->setDecorators(array(
'ViewHelper',
'Errors',
'Description',
array('HtmlTag', array('tag' => 'dd')),
array('Label', array('tag' => 'dt')),
));
and in your view script:
<?= $element ?>
Is this mixing display logic and business logic? Yes, kind of. Unless
you think of the element or form as a mini-MVC, in which case you see
that the decorators are the view, and the filters and validators are the
model. The fact is, you can use Zend_Form as _just_ an input filter, or
even as _just_ the view layer. But combined, they an actually help
reduce some code and some code duplication. (Particularly if you attach
the form to your model, making your model now renderable *as a form*.)
--
Matthew Weier O'Phinney
Software Architect | [EMAIL PROTECTED]
Zend Framework | http://framework.zend.com/
