[Catalyst] Forms generation

[Bill Moseley]

On Thu, Jun 14, 2007 at 11:34:52AM +0200, Leo Cacciari wrote:
>   Let us start by considering the CURD example contained in
> Catalyst::Manual::Tutorial::AdvancedCRUD. In this example, the user
> enters his or her data using a form generated by the controller using
> HTML::Widget. While this approach presents the  non negligible advantage
> to allow easy validation of entered data, and even automatic population
> of a database object, it has IMHO a problem in making the controller
> aware of things that should be known only to the view, namely how to
> actually compose the form in HTML, or even that a HTML form should  be
> used at all (what if I want to use something like Catalyst::View::Wx for
> my user interface generation?).

That was my thinking.

    http://search.cpan.org/~hank/Form-Processor-0.10/

still needs a few tweaks as needs arise.

There's a simple demo Catalyst application in the t/example directory of:

    http://search.cpan.org/~hank/Catalyst-Plugin-Form-Processor-0.01/

Also look at:

    http://search.cpan.org/~jsiracusa/Rose-HTML-Objects-0.548/

which is more about widget generation (which is very nice) but less
about interfacing with the database automatically, IIRC.  Not that it
wouldn't be easy to add on (which I did once).


>    As I see it, the controller should tell the view 'I want the user
> entering the following data, each one with its data-type, and obeying
> the following constraints".

I take that a step further, and say that the controller should say
only "I want the user to update their profile"  and the controller
shouldn't have to worry what fields and field types the "profile" is
made up of.


> But it is not the work of the controller to
> say _how_ the form should be presented to the user. Just as an example,
> if the user is supposed to choose one among several alternatives, it is
> a view decision if present the user with a drop down list, or a list of
> radio buttons. The only thing the controller is interested in, is that
> one, and only one among the proposed alternatives is chosen by the user.

And along those lines, I use a template to generate the HTML and for
basic crud forms the template decides if to show a drop down list or a
list of checkboxes (multiple select) or radio buttons based on how
many options there are.


>   What I'd like, is to have the controller generate a "generic user
> interface form object" and pass it to the view. The view would the use
> the object to generate the actual form presented to the user. 
> 
>   On reception of the request, the controller would have to find the
> object filled up with the user entered data (using some plugin[1]), and
> be able to check the constraints (via some "verify" method), and maybe
> use the object for actually filling a database object.

Again, you have a form object, so the controller only needs to know if
the entire form is valid or not -- the controller decides what page to
show, so it only needs to either show the form page or the "Profile
Updated!" page.  It's up to the form to know if the input data is
valid or not.  The form is an object, so it can have its own behavior.

So my controllers to update/create look like:

    sub profile : Local {
        my ( $self, $c, $user_id ) = @_;

        $c->post_redirect( 'list', 'Profile Updated!')
            if $c->update_from_form( $user_id );
    }




-- 
Bill Moseley
moseley at hank.org