hey_david has asked for the wisdom of the Perl Monks concerning the following question:

Wise Monks,

I've been thinking of ways to simplify and automate the development of web form applications, to speed up the process and make them easier to maintain.

I'm thinking of a scheme where once the framework is developed, then for each form, almost all (an exageration) you'd have to do is define your form in a property or XML file. In it might be a descriptor for each field, something like:

[field name]
type=[text|checkbox|radio|single_choice_listbox|multi_choice_listbox]
validation_type=[none|zip|state_abbr|email|phone|date|year|integer|alp
+hatext|...] 
required=[yes|no]
dependent_fields=[field_x, ...]
choices=[<id:display_name>[,...]] (for choice-type fields. E.g. 1:Blue
+,2:Red,...)

[download]
If you wanted to use these descriptors to generate the form as well, then perhaps you could add:

order=<1..n>
pre_text=[text], ex: Birthdate:
post_text=[text], ex: (e.g. mm-dd-yyyy)
start_on_new_line=[yes|no], default is yes
size=[no. of characters], default is undefined, only valid if type is 
+text type
maxlength=[no. of characters], default is undefined, only valid if typ
+e is text type

[download]
WHAT could you do with this?

- Generate the form on the fly in an html table (which you could say, capture in a string, and pass to a cgi print statement or a template, for example). Includes filling in listboxes and such with static values.

- Check for required input, and mutually dependent field input

- Validate form fields. The above validation_types would reference into a set of validation objects, be they home-grown or from existing validation modules

- Submit data into a given database table (using a one-to-one mapping between form fields and table columns)

- Retrieve data from the same table and fill-in the form when desired.

- And if you wanted separate database tables for the static choice values associated with listboxes, checkboxes, etc., you could run a script at installation time that would read this property file and create the database tables, with suitable key constraints.

I realize there are some issues to settle, e.g. better ways to separate the model of the data from its view, and ways to make it extensible.

I also realize I cannot be the first person to have thought of something like this (or something much better, no doubt).

Good monks, before I plunge down this path, let me learn from your insight and experiences. Your comments, suggestions, and/or links to other posts would be greatly appreciated.

Thanks!

David

Replies are listed 'Best First'.
Re: Developing Web Form / Database Apps Faster, Better
by Enlil (Parson) on Oct 13, 2003 at 22:46 UTC
    A lot of the functionality (not quite all of it), that you mention above is already found in CGI::FormBuilder. Though I have only tinkered with this module, it does have an excellent website (with a lot of information about it's use). Of the things listed above it does do validation, support for Text::Template and HTML::Template.. well have a look for yourself at what else it can do.

    Good luck on your quest.

    -enlil

[reply]
Re: Developing Web Form / Database Apps Faster, Better
by etcshadow (Priest) on Oct 14, 2003 at 00:47 UTC
    Well, I've been there and done that, and the summary is: don't do it.

    It was just too difficult to tailor the individual forms to their specific purposes. Also, this may be nice enough for a very quick first cut at an application, but my experience was that you immediately have to start putting more business logic into the individual forms.

    Also, it goes without saying that getting the forms' layouts to look reasonable is a nightmare... You either:

    • try to make some super-smart logic for laying out the forms automatically (it won't work that well, in the end).
    • limit the form functionality in order to facilitate the automatic layout, thus hamstringing the more important aspects of your application for the less important.
    • make it so manipulable and controllable that you haven't really gained anything for your efforts.

    But I'm not just saying this to be negative, because I can also tell you what did work for us: Make or find (or find and customize) some good, reusable utility code for these forms (to do all of the commonly repeated tasks). What you get out of this is:

    • the actual forms are pretty thin, but contain all of the important logic.
    • the forms aren't just data structures, so you can really do anything with them.
    • you use the same utility code for complicated application screens (well beyond simple, auto-generatable forms).
    • those last two points, together, allow you to evolve simple forms into non-simple forms in an organic way, as requirements shift. Also, you don't have to look at your simple forms and your complicated forms as two different things... much like how a simple script can become a bigger program as the complexity of the task grows. It's like: rather than starting from a shell script and having to recode it halfway through to a java app, you just start in perl, and finish in perl.

    Unfortunately, I can't post any sample code for this, because the work I'm referring to was proprietary... but I'm sure there is some similar stuff on CPAN. Anyone else have specific recomendations?


    ------------
    :Wq
    Not an editor command: Wq
[reply]
Re: Developing Web Form / Database Apps Faster, Better
by bradcathey (Prior) on Oct 14, 2003 at 01:09 UTC
    I agree in theory that this would be a real timesaver. I have developed similar tools to help ease the pain of creating those pesky forms, and the CGI code to process them, but not to the degree you are trying to achieve.

    However, what I have learned in the process is that there are so many options to consider for each step, that the time it takes to develop and debug a working program well exceeds the time of just cutting and pasting existing code and then going back to tweak parameters.

    For instance, text input. There are the parameters of size, maxlength, value, not to mention css styles or javascript events. And then the validation stuff. Drop downs (Select/Option) are even trickier.

    I couldn't figure out an elegant way to do using only Perl. So here are two examples of a table creator and element creator using HTML and Javascript that calls a Perl script. However, I've run out of steam in writing the Perl to generate the final table and form.

    Maybe my problem is I'm too picky and want to create all these complicated forms, therefore increasing the workload. Maybe your way is a lot more elegant.

    My advice is to write a test script to see what you're minimally up against before committing the time to it.

    Best of luck!

[reply]

      Hi brad,
      I saw your table creator and element creator forms.
      The idea is nice and i had also flirted with it once.
      I was wondering if i could have a look at the perl scripts behind those forms (hope its not proprietarty :))
      Thanks and regards, chimni

[reply]
      Thanks for your replies.

      Enlil, I did look at CGI::Builder, and went through its tutorial. I wish I'd seen it a year ago. It's obviously a fairly mature piece of work, and the documentation is excellent.

      etcShadow and bradcathey, I take your cautionary advice to heart, and am thinking of shying away from my original plans for an all-in-one solution.

      Thanks again,

      David

[reply]

Back to Seekers of Perl Wisdom