As the author of Form::Processor I wanted to add a few comments.

Form::Processor is new to CPAN and still has some rough edges, of course, and won't tickle everyone's fancy. After all, it's just code I was using in my own projects. But, I'd love to have help extending it -- for example in adding a DBIC model class in addition to the existing CDBI model class. (Better docs might not be a bad idea, either...)

First, Catalyst users may wish to look at the plugin Catalyst::Plugin::Form::Processor which simplifies things a bit. There's also a sample application included that makes it easy to try the module.

That plugin demonstrates the concept of the module -- that forms are objects and that the form should know how to populate itself from the database (including valid options), how to validate itself, and how to create or update data in a database. I really don't want to be bothered with that in the application code (e.g. in a controller). For example:

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

        # Validate and insert/update database
        # simply display form (again) if does not validate
        return unless $c->update_from_form( $user_id );

        $c->post_redirect('list', 'User updated' );
    }
[download]

Second, the review says Form::Processor does not generate HTML. That is true, but it's also by design as my interest was in moving data back and forth between the user and a database, not so much in displaying forms (HTML or otherwise). That said, there is an included example TT file that will generate the HTML in the Catalyst Plugin.

I find it very rare that forms are so basic that they can be completely auto-generated. It's like scaffolding: great to demonstrate something quickly but not so useful when you get into the realities of an application. Where validation messages appear, label layout, javascript validation, localization (although error message localization is supported), etc. are all display issues so I wanted to leave that to the template system and CSS. And frankly, it's just not that hard to generate the html.

Form::Processor is based on the design of Rose::HTML::Objects. I recommend checking out that module. But, again, that module tends to focus more on the HTML side than the database side. But, John does amazing work and I really think anyone looking at form processing should consider that module.

Similar to Rose::HTML::Objects, in Form::Processor the forms are objects as well as the individual fields. Fields can be sub-classed, of course, so new fields can be created based on existing fields. The idea is that your application probably has specific data types that are used in multiple places so it's expected that custom fields would be created for each application. Fields can also be (contain) forms, which is one way to create compound fields. That means you can also build forms from other forms, but I've rarely needed to do that. (It's a bit kludgy, but has worked ok so far.)

Finally, I've never been sold on the configuration file-driven forms, such as describing the forms in YAML. Works for the general case, but my forms almost always have custom validation needs, custom option population, special needs when fetching or updating data from the database, etc. Kind of hard to describe in a config file. Having each form as a separate module solves that, plus it keeps everything form-related in one place. That said, if your forms are trivially simple (just simple create/update without any extra validation needed), building forms from YAML would be just a few lines of code. For simple forms I just pass in the form structure when calling new().