...meaning Yet Another HTML Module. I've come up with a module called FormManager.pm that I've been using quite a bit in recent projects. I'd like the opinions of the fine monks around here as to whether it's worth turning into a CPAN module, or if it's the hacked-up, cobbled-together redundant version of something else as is often the case. For me, it's shaved off quite a bit of development time. Here's an example 
use FormManager;

my $query = new CGI();

my $fm = new FormManager
  (layout =>
    [new FormManager::Text (name => 'phone_number', heading => 'Enter 
+your phone number', validate => 'phone'),

    new FormManager::Select (name => 'likes_ice_cream', heading => 'Do
+ you like ice cream?', option_list => ['Yes', 'No']),

    new FormManager::Hidden (name => 'action', value => 'submit_this_f
+orm')
  ],
  form_submit => 'Submit this form'
);

print "Content-Type: text/html\n\n";

# This script can be called in two ways
# 1) Initially to get the form
# 2) By submitting the form

# If this is case 1) 
if ($query->param ('action') ne 'submit_this_form') {
  print $fm->getHtml();
}
else {
  # Ensure that the input is valid.  If not, re-print the form
  if (!$fm->processQuery()) {
    print $fm->getHtml();
  }
  else {
    print "Your phone number is : " . $fm->getValue ('phone_number')" 
+. " and you " . ($fm->getValue ('likes_ice_cream') eq 'No' ? "don't l
+ike ice cream." : "like ice cream.");
  }
}

[download]
There are numerous features this provides over pure CGI.pm.

1) It's easily extensible. For instance, one could create a FormManager::Date component which consists of three select boxes for month/day/year. In your code, you could treat this as a single input.

2) Validation. This module can validate in a number of ways. So you can use the premade options like 'phone', 'integer', etc, or create your own. Select boxes are automatically checked to ensure the value matches one of the options presented. Validation of all form components is done with a single call to processQuery($query).

3) Easy user-friendliness. If someone enters an incorrect value, or leaves out required information, simply call $fm->getHtml() again after validation. FormManager will fill in all of the old values so that the user doesn't have to re-enter an entire form because of one mistake.

Thanks in advance for the perl-wisdom of the ages.
James

Replies are listed 'Best First'.
Re: Is there room for YAHTMLM?
by Ovid (Cardinal) on Feb 27, 2003 at 21:10 UTC

    Without even considering what your module does, I think the following questions should be asked and answered:

    • What problems are you trying to solve?
    • Why are you trying to solve it?
    • What other solutions are available?
    • Why is your solution better?
    • What limitations arise from your solution?

    One of the first modules I considered uploading to the CPAN involved debugging CGI programs. After a bit of research, I quickly discovered that I added only marginal value, and the costs of my solution outweighed the benefits. Hence, the module is not on the CPAN.

    However, if you feel that the benefits outweigh the costs, then seek input from others (which you are doing) and see what they have to say. While Perlmonks has been an excellent resource on getting my problems solved, I feel that it's been a mixed bag regarding code reviews. A classic example is tachyon's RFC CGI.pm refactoring. Many monks discouraged him and he had to follow up with CGI::Simple vs CGI.pm - Is twice as fast good enough?. The CGI module, while very popular, is getting on in years and needs some competition. Competition is a good thing, but reinventing the wheel needs very serious consideration.

    To get better feedback, you may wish to try the module authors list. Again, I've had mixed results, but since I strongly encourage well-thought out competition, I say go for it!

    That being said, your module seems like a stepping stone between CGI.pm's HTML generating functions and using a proper templating system. There is definitely a gap, but I am not sure of the value of filling it.

    Cheers,
    Ovid

    New address of my CGI Course.
    Silence is Evil (feel free to copy and distribute widely - note copyright text)

[reply]
Re: Is there room for YAHTMLM?
by jonadab (Parson) on Mar 01, 2003 at 19:14 UTC

    General comments:
    The getHTML() method is okay to have, but what you will probably want is a getform() method (or getHTMLform() perhaps) that returns only the part from <form up through </form>. That allows multiple forms on the same page (only one of which will be submitted at any time, of course -- each form can have a hidden input that indicates which form it is, to prevent any ambiguity), arbitrary additional content, and, in general, more flexibility. Make sure your form html is wellformed xhtml, too. Ideally it should validate.

    For instance, one could create a FormManager::Date component which consists of three select boxes for month/day/year. In your code, you could treat this as a single input.

    That sounds to me like it ought to be included (eventually), because it would be a generally useful feature. Bonus points if it has separate methods to return the date in MySQL format or the way localtime does, depending on what the calling code is going to do with the data.

    Validation

    That alone, IMO, makes it worth having in addition to CGI. Your methods for getting the form input could internally rely on CGI.pm if it will do what you need, but putting the validation layer on top is a significant improvement. If there's not another well-done module out there that handles this, then yours would be a Good Thing.

    To go a little further with that... on failure, it ought to generate a reference (to a hash or something; the internal implementation is unimportant, since it can be treated by the calling code as a magic token) that can be retrieved by the calling code and passed to the next call to getHTMLform() (or whatever) to cause the sections of the form relevant to the failure to be marked up with a "validationfailure" class, so that the calling code can easily style them with a red outline or somesuch. 

    for(unpack("C*",'GGGG?GGGG?O__\?WccW?{GCw?Wcc{?Wcc~?Wcc{?~cc'
.'W?')){$j=$_-63;++$a;for$p(0..7){$h[$p][$a]=$j%2;$j/=2}}for$
p(0..7){for$a(1..45){$_=($h[$p-1][$a])?'#':' ';print}print$/}

    [download]
[reply]
[d/l]
[select]
      Actually, there already is a getForm() function. I've also included a FormManager::Html component for people who just want a quick and dirty way of making a form, or want to include arbitrary html between the fields.

      On the Date component - the plan is to make it have options for begin/end time (only show 2001-2010, for instance), different date formats, etc. Eventually I'd like all components to be as flexible as possible in terms of how information is handled, but as far as the actual display goes, I'd like to force the user to use stylesheets. Right now I'm still working on fleshing the whole thing out (radio buttons aren't implemented, for instance).

      On validation - right now the default is to display errors if validation fails. It's pretty basic right now : "Field : 'Car Speed' must be a number". Errors are displayed in red at the top of the field. There's also an option to suppress them or simply retrieve them as an array if so desired.

      Anyway, thanks for the feedback and suggestions.
      James

[reply]

        Sounds like you're a step ahead of me :-)

[reply]
lots of web form validation packages already
by markjugg (Curate) on Jul 09, 2003 at 14:45 UTC
    Before proceeding futher, I would 'See Also':

    Personally, I like using Data::FormValidator and CGI::Application::ValidateRM, and am beginning to use a hacked version of HTML::FormEngine::DBSQL to generate forms from a Postgres database table.

    Mark

[reply]

Back to Meditations