in reply to Form Processing

In a world of “TMTOWTDI,” it is impossible to characterize form-processors. Different modules have been designed with different scopes.

For example, HTML::FormFu, as its name implies, offers everything. It's a “cradle-to-grave” solution, and if you happen to need many hundreds of data-input forms and subforms, all closely tied to underlying database structures (and especially if those structures are changed frequently), you can exploit this module in just the way(s) that the designer intended.

Even so, there are numerous ways to get there. Form creation, data collection from the HTML input-stream, validation and cross-validation, and HTML output are all separate processes, and so, “they can be separated, or not.” You don't have to use everything that a package offers you.

In my most-recent application, for example, I did things quite differently. I used HTML::FormHandler to define input-forms, in the sense that they are “a means for capturing POST-inputs and validating them.” The generation of all the screens is done with the venerable Template::Toolkit. However, in a few cases I do avail myself of HTML::FormHandler::Render::Simple. Since all of my applications' data is stored in persistent Perl objects, the form-handler's data model layer has been customized to do that ... and to capture and interpret any exceptions that may be thrown by the objects when they refuse to accept what they have been kindly offered.

One of the very useful services that a form-handler provides is, of course, validation and therefore error-message generation, but it's up to you what (if anything) you actually do with that message. A form-field will provide you with the basic ability to discover whether or not it “is valid,” or “is empty” and so-forth, or that it “has an error.” Other higher-level functions will use this to produce an error-message, if you choose to employ those higher-level functions in your app.

It is important to remember that form handling and HTML templating are not the same concern. In my case, for example, just about every page of the application wraps its entire content in a <FORM> tag... but that's just how the templates are designed.

Final comment:   at the very bottom, the most-basic foundation, we still have the venerable CGI module, which is a rock-solid way to interpret an HTML data stream. As far as I know, just about everyone uses it.

Replies are listed 'Best First'.
Re^2: Form Processing
by sundialsvc4 (Abbot) on Mar 25, 2009 at 13:31 UTC

    #%@#%!!” ... forgot to log-in again! Anyway, “that's my post.”

Re^2: Form Processing
by zby (Vicar) on Mar 25, 2009 at 14:40 UTC
    I certainely agree that this is a very foggy area - and most probably you are right that one cannot make a strict definition of form processing that everyone would accept. But in my view this is exactly what makes it an intersting discussion subject :). I thought it would be enlightening to gather all the opinions (and here I need to thank you for yours :).
Re^2: Form Processing
by zby (Vicar) on Mar 27, 2009 at 09:16 UTC
    By the way - you might want to join the FormHandler mailing list or show up at #formhandler on to discuss its future changes.