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:
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.