# This is the run mode that will be validated. Notice that it accepts
# some errors to be passed in, and on to the template system.
sub form_display {
  my $self = shift;
  my $errs = shift;

  my $t = $self->load_tmpl('page.html');

  $t->param($errs) if $errs;
  return $t->output;
}

sub form_process {
  my $self = shift;
 
  use CGI::Application::Plugin::ValidateRM (qw/check_rm/);
  my ($results, $err_page) = $self->check_rm('form_display','_form_pro
+file');
  return $err_page if $err_page; 

  #..  do something with DFV $results object now
 
  my $t = $self->load_tmpl('success.html');
  return $t->output;

}
 
sub _form_profile {
  return {
    required => 'email',
    msgs => {
      any_errors => 'some_errors', 
      prefix     => 'err_',
    },
  };
}
[download]

I've not used them, but it might be worth adding:

• CGI::FormBuilder
• FormValidator::Simple

A complete sidebar, but something for the people reading this. There are other things that are somewhat app-specific, but have some good points that can be built upon or even just taken if the license permits.

I hate tooting my own horn, but a few people have found it worth stealing for their projects: Mango::Form. It uses a hybrid config of CGI::FormBuilder for the form definitions with FormValidator::Simple config for the validation all in the same config file. The CGI::FB validation wasn't as good as FV::S for me, so the two got married together.

    ---
    name: myform
    method: POST
    javascript: 0
    stylesheet: 1
    sticky: 1
    submit: LABEL_CREATE
    fields:
      - sku:
          type: text
          size: 25
          maxlength: 25
          constraints:
            - NOT_BLANK
            - LENGTH, 1, 25
            - UNIQUE
      - name:
          type: text
          size: 25
          maxlength: 25
          constraints:
            - NOT_BLANK
            - LENGTH, 1, 25
[download]

I'm sorry, I'm AM self-whoring now. :-)

I should also mention, and I think this is an important thing to list on all of the modules above, is support for message/error/label localization, both internally in the modules, or externally via callbacks or something.

In the case of Mango::Form, labels default LABEL_FIELDNAME and error messages default to FIELD_CONSTRAINTNAME. These can be overriden in the config above, but are all mostly passed through L18N like Maketext, or the Catalyst::Plugin::L10N or other such things.

Once people find a good form handler, then a good validator, the next things that usually bites is the localization of grouping of the messages themselves.

i would suggest that if you're going to put code tags in a table cell, trim all uniform leading whitespace -- top level lines can be in column 1 -- and use 2 psace "tabing" instead of 4.

I'm not trying to start a holy war of general code formatting or anything here, i'm just saying: if you want to put code in a little box, don't make it any wider then it has to be.

Glad someone is taking this on. Can't wait to see it on the wiki. Some other possible points of comparison:

• validation
  • does the package provide it's own system of validation rules, and if so, is the system customizable/extensible?
  • does the package support one or more third-party validation packages, and if so, which ones?
• form construction/definition
• does the package support config-file-based form construction?
• does the package support dynamic (run-time) form construction/modification?
• framework integration (e.g. CGI::App, Catalyst, etc.)

I second perrin's suggestion to review Rose::HTML::Form from the Rose::HTML::Objects dist. I haven't used it yet, but from what I've seen it has some unique and interesting features:

• form classes can include code for pre- and post-processing; you can embed methods to populate the form from objects and/or construct objects from submitted data, or you can embed your model/db interactions directly
• forms can be nested/aggregated with automatic fieldname subscripting; e.g. you can design a PersonForm for name info and an AddressForm for contact info, then display and process them as a single submission
• basic field types (e.g. checkbox groups, selectboxes) can be subclassed to create reusable custom field types with their own specific validation, input and output filtering, and even compounding of multiple sub-fields

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().

Replying to all mentioning Rose::HTML::Objects - it is on my task list (but if someone would create that table row table for me I would just include it - this might be faster :).

Ad HTML generation (and configs ) - don't be defensive here - there are people with similar views as yours and for them no HTML generation (or configs) would be a feature.

By the way I really like the brevity of the Catalyst controllers using Form::Process - thumbs up.

HTML::FormFu does have database integration, in DBIx::Class::HTML::FormFu.

Updated - thanks. I don't like the fact that it requires that you add form related code to the database - that's probably why I forgot about it.

A wiki page would be more convenient for that – but for now I have no access to some suitable wiki

Try the Perl 5 wiki. It already has an overview page with lists of Recommended CPAN modules, such as the various Web Frameworks. An overview of form processors like yours would fit right in.

Makeshifts last the longest.