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$/}
In reply to Re: Is there room for YAHTMLM?
by jonadab
in thread Is there room for YAHTMLM?
by jbeninger
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |