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.