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

In reply to Developing Web Form / Database Apps Faster, Better by hey_david

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


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.