Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Ovid (2709)

Ovid
  (email not shown publicly)
http://publius-ovidius.livejournal.com/
AOL IM: ovidperl (Add Buddy, Send Message)

Stuff with the Perl Foundation. A couple of patches in the Perl core. A few CPAN modules. That about sums it up.

Journal of Ovid (2709)

Thursday April 27, 2006
01:33 AM

Class::CGI mailing list

[ #29457 ]

I have just set up an email list for Class::CGI. If you're interested in using Class::CGI, having design discussions, wish to contribute patches, etc., then please sign up for the list. Development is ongoing and I look forward to having others have a role in the evolution of this module.

New handlers I am thinking about:

Class::CGI::Email::Valid
Validate email addresses. Will not untaint them.
Class::CGI::Digest::SHA1
Verify that form parameters have not been altered.
Class::CGI::Digest::MD5
Verify that form parameters have not been altered.
Class::CGI::Number::Phone
Validate and return Number::Phone objects (could be tricky).
Class::CGI::CreditCard
Validate and return a Business::CreditCard::Object.

Also note that I am not bundling these in the Class::CGI distribution as folks should be able to pick and choose which handlers they wish to implement. I will, however, be creating a Bundle::Class::CGI for folks who want all of it.

Other planned features are support for "required" fields. The API I envision looks like this:

use Class::CGI
    profiles => $profile_file,
    required => [qw/customer order email/];

Of course, specifying the handlers in your code directly should also work:

use Class::CGI
    handlers => {
      customer => 'Handler::Customer',
      order    => 'Handler::Order',
      email    => 'Class::CGI::Email::Valid',
      phone    => 'Class::CGI::Phone::Number',
    required => [qw/customer order email/];

This raises some interesting design questions. For example, the "customer" parameter may be a virtual parameter comprised of "first_name", "last_name", "address", and so on. Because Class::CGI merely delegates those parameters to handlers, it cannot know whether or not those are virtual parameters. Thus, the handlers will be responsible for checking if they're required and reporting if they are missing.

I also need to support a distinction between "invalid" and "missing" parameters and overriding error messages so you can customize them for your site. I welcome feedback from folks on what they would like to see.

Yet another feature which may be important is allowing one to fetch the form data from something other than CGI::Simple, while retaining that as the base class. I have a way of making that very simple, but that's another discussion entirely. The major aim is to make the simple things simple, the hard things possible, and keeping the code as simple as possible. Feature creep is inevitable, but I strongly, strongly desire to keep things small. It's OK if handlers become a bit more complicated to write as they'll be "write and forget" code. It's the day-to-day application code which must be so ridiculously simple that the end-users need not worry about the difficult bits.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.