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
Ovid (2709)
Ovid
(email not shown publicly)
http://publius-ovidius.livejournal.com/
AOL IM: ovidperl (Add Buddy, Send Message)
(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.
Friday April 07, 2006
05:31 PM
RFC: Class::CGI
A long time ago, I mused about fetching objects directly from HTML forms instead of grabbing the ID, untainting it, validating it, and instantiating a new object. I finally wrote up a proof of concept. You can read about it at Perlmonks. Basically, it lets you do stuff like this:
use Class::CGI
handlers => {
customer => 'Class::CGI::Customer'
};
my $cgi = Class::CGI->new;
my $cust = $cgi->param('customer');
my $email = $cgi->param('email');
# validate email
$cust->email($email);
$cust->save;
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
I pour myself a cup of strong coffee. :-)
-- Jarkko Hietaniemi
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.
I can see your future (Score:1)
First you'll want to auto-inflate a single param, so you'll do what you have now.
Next, you're going to want to have more than one CGI param for each object. So you can do things like composite dropboxes and so on.
Then you are going to want to define a whole group of these in one hit, so you can have something like Class::CGI::Form,
Re:I can see your future (Score:2)
First you'll want to auto-inflate a single param, so you'll do what you have now.
Yup. Got that.
Next, you're going to want to have more than one CGI param for each object. So you can do things like composite dropboxes and so on.
Yup. Added that a few hours ago. It was a simple matter of fixing an egregious design flaw in my original code.
Then you are going to want to define a whole group of these in one hit, so you can have something like Class::CGI::Form, which would extract a whole bunch of
Re:I can see your future (Score:1)
What if you trust a Class::CGI-instantiated object to be something, and someone just changes the spec on the page...
The other steps I missed after those, is that once you have a Class::CGI::Form-like thing, you'll want to automatically generate those based on things like Class::DBI classes.
And that means to some degree the program itself needs to control wha
Re:I can see your future (Score:2)
First, the __PROFILE__ would be strictly optional. You're always at liberty to declare the handlers in your code instead.
Second, I agree with what you're saying about a security hole. I should add a signature check if profiles are listed in the HTML.
Re:I can see your future (Score:2)
In thinking about this more, I see that the benefits of having forms declare which handlers they need are outweighed by the security issues. I'm pursuaded enough by your arguments that I think I'll abandon __PROFILE__ declarations in the HTML. Thanks for kicking me.
Re:I can see your future (Score:1)
It's called XForms
But in the case of XForms, it's able to leverage Schema validation to deal with it's evil problem.