[Catalyst] Forms generation

[mreece at vinq.com]

> On Thu, Jun 14, 2007 at 11:33:17AM -0700, Michael Reece wrote:
>> i've been looking at Form::Processor and similar, but the tricky bit
>> for me is that i want the view to be both responsible for generating
>> the HTML and deciding which fields belong on which form, without an
>> intermediate form object that has to inform both the view and
>> controller.
>
> You can't let the View decide because the client can post whatever
> they feel.

right, this my attempts to let the view still decide, without trusting the
client post, by letting the view register (in the session) exactly which
fields were provided, and then have the controller look at only those
fields.

>   And I the Controller shouldn't have to bother with
> individual fields, but just if the entire post is valid or not (as the
> controller needs to know what page to return).

i've been leaning towards the models providing the validation profiles for
whatever subset of fields the view was allowed to render.

> But say someone wants to change their password -- you have to validate
> that the old password is correct, the new password matches the
> "Enter password again:" field, and that they are different from the old
> password.  How do you communicate that logic back to the controller or
> whatever in the session?

the answer is by allowing the model to provide the validation coderef for
the password field, which notes it has a dependency on the old_password
and password_confirm fields, makes the appropriate comparisons, et al.

> It makes sense to have a separate form object to handle that work.

i'll probably realize that as soon as i try to swap DFV for RHTMF or
other, and wish i had abstracted or adopted a general API, but until then
i'm happy enough with models returning DFV validation closures, et al..

but only if that also supports my goal of not having the authoritative
list of fields to be rendered defined in a .pm or .yml file, but in the
.html template where it belongs imho.