Beefy Boxes and Bandwidth Generously Provided by pair Networks
XP is just a number

comment on

( #3333=superdoc: print w/replies, xml ) Need Help??

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.

In reply to Re: Form Processing by Anonymous Monk
in thread Form Processing by zby

Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post; it's "PerlMonks-approved HTML":

  • Are you posting in the right place? Check out Where do I post X? to know for sure.
  • Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:
    <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>
  • Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
  • Want more info? How to link or or How to display code and escape characters are good places to start.
Log In?

What's my password?
Create A New User
Domain Nodelet?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others having an uproarious good time at the Monastery: (2)
As of 2022-05-16 19:08 GMT
Find Nodes?
    Voting Booth?
    Do you prefer to work remotely?

    Results (63 votes). Check out past polls.