-- Ionut Gabriel Stan <[EMAIL PROTECTED]> wrote
(on Friday, 28 November 2008, 08:17 PM +0200):
> Matthew Weier O'Phinney wrote:
> > -- Ralf Eggert<[EMAIL PROTECTED]> wrote
> > (on Friday, 28 November 2008, 06:23 PM +0100):
> > > > What I've started doing and recommending is to attach forms to your
> > > > model, and to use forms for model validation.
> > > >
> > > Thanks for your reply. Your approach sounds very sensible to me. But I
> > > am not sure how you handle different forms for the same model. In my
> > > example I have different forms which use the same validator and filter
> > > definitions for the same fields.
> > >
> > > Would you define the validators and filters for the username field in
> > > all three forms? If you want to change these rules for the username
> > > field you need to change these definitions in each form, don't you?
> > >
> >
> > I typically define forms explicitly as discrete classes -- and the same
> > for elements. What I would suggest is that if there are common elements
> > you use across multiple forms that will be using the same
> > validators/filters/decorators/etc... then create a custom element:
> >
> > class My_Form_Element_Username
> > {
> > public function init()
> > {
> > $this-> addValidators(array(
> > 'Alnum',
> > array('StringLength', false, array(6, 20)),
> > ));
> > $this-> setRequired(true);
> > }
> > }
> >
> > In your form classes, use these custom elements. That way, if you change
> > the rules for a single element type, it will propogate to all forms that
> > use it.
> >
> >
> > > And how do you handle different forms for the same model, say the create
> > > form is different than the update form?
> > >
> >
> > A single model can certainly have multiple forms -- the example I
> > displayed was just a simple one.
> >
> > Have a getter for each form, or have getForm() accept an argument
> > indicating the form to retrieve.
> >
> >
> Wouldn't be better a reversed relationship, i.e. a series of forms have
> a setter setModel() and the whole validation
> logic is inside the model (the place that I think is the most appropriate) ?
>
> Ralf said "And how do you handle different forms for the same model, say
> the create
>
> form is different than the update form?"
>
>
> IMHO this is a case where validation should stay in the model and the
> form would have access to the validators
> in the model. Also, there is no need to duplicate a setForm() method or
> add parameters to it.
> I came to this conclusion after I realized that Zend_Form is just a very
> specialized controller + view. The only thing
> missing is the model.
It really depends on your point of view; I can see arguments for either
case. When I was developing Zend_Form, I made a conscious decision that
both Zend_Form and Zend_Form_Element would implement
Zend_Validate_Interface -- so that they could be used as
validation/filter chains for models. When you think of forms this way,
then what you're suggesting is still true: validation logic is inside
the model, and encapsulated in its own object.
I would argue that forms aren't really controllers -- they know nothing
about their environment, whereas a controller does. You must pass them
data to process. That said, I can see how the presence of decorators can
make this less obvious.
The other reason I'd argue against passing the model into the form is
for use with services. As an example, in the pastebin demo I referenced
earlier, I was able to expose my models as services very trivially in
large part due to the fact that validation was self-contained in the
models via the form objects. This is a great way to re-use and
re-purpose models for a variety of domains.
--
Matthew Weier O'Phinney
Software Architect | [EMAIL PROTECTED]
Zend Framework | http://framework.zend.com/
