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)

Wednesday August 25, 2004
06:56 PM

CGI parameters as objects

[ #20569 ]

I've been toying with the idea of creating something like this:

use CGI::Simple::AsObjects
    handle => [qw/Customers Products/];

my $cgi = CGI::Simple::AsObjects->new;
my $customer = $cgi->cust_param('customer_no');
print $customer->name; # objects directly from the CGI request

Still, if you know OO Perl, do you still use CGI, or would anyone even want this? I think it's a useful idea, but I'd have to play with the interface. The import list is almost like traits in that you can have a variety of specialized "param" methods automatically available and you can fetch an object directly back from an CGI parameter without the tedious hassle of validating the object ids and instantiating the objects.

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.
  • How do you map form fields to objects? Is there a way that you have to do that without a lot of work?
    • Something like CGI::State maybe?
    • If you are just writing a small script or two, this would be overkill. However, if you're building a large system, I think the setup would be worth it. Going with Juerd's name of "Class::CGI", I am thinking something along the following lines, with three required subs:

      package Class::CGI::Customer;
      use My::Customer;
      use Class::CGI;

      sub register {
        name   => 'Customer',
        method => 'cust_param',
        param  => 'cust_id',    # can be overridden
      }

      sub validate {

      • You should call a register method in Class::CGI, not define one that it is supposed to track down and call. Also you need to figure out how to handle conflicts where two different objects use similar parameter names.

        However when you finish your module and flesh it out, you'll probably discover that you've started writing a controller in an MVC pattern.

        • I was certainly considering the issue of handling conflicts. That could get annoying, particularly if a given controller does not use the conflicting packages but some poor sod gets bitten by it later down the road.

  • Nice idea, but can you call it Class::CGI then, like Class::DBI? It's shorter and IMHO nicer to look at. After all, they do almost the same, do they not?
  • I have a class that combines Data::FormValidator and some other things so I can write:

    my $addr = Foo::Address->new($cgi);
    if ($addr->is_valid) {
      # XXX
    } else {
      print "The following fields are missing or invalid: ", join("\n", $addr->errors);
    }

    It has a few neat features including supporting a prefix so if you have two addresses in the same field you can use:

    <input type="text" name="addr1.name">
    <input type="text" name="addr2.name">

    and:

    my $addr1 = Foo::Address->new($cgi,

    • Very cool idea! Could it work in conjuntion with something like CGI::Untaint or Class::DBI::FromCGI? Any chance this could be released to CPAN? How do you handle testing with your object level validation - dummy CGI object?

      I have something similar to you except I combine the validation at a higher level when deciding if a form should be processed or simply displayed. So I can't do the individual object level validation like you're doing. Any errors from D::FV are eventually stuffed into the template param

      --
      "Perl users are the Greatful Dead fans of computer science." --slashdot comment
      • I've been thinking about the client-side JS validation recently. What my plan is:
        1. Write something like D::FV but with a more flexible store for the rules
        2. Have a JS version of this
        3. Use one of the SpiderMonkey based CPAN modules to test Perl vs JS
        4. Release to CPAN
        5. ...
        6. Profit!

        • My thinking was to have the validation module be able to write a JS function (ie. check_form() ), that would do at least the easier checks. This of course requires some other template support to automatically set the onSubmit attribute of the appropriate element. The checks would just cover the simple cases: required field & dependencies. If this field is not present, then fail. If field a is "foo", then fields x & y are also required. I want to do it all in a single module, which can then be tran
          --
          "Perl users are the Greatful Dead fans of computer science." --slashdot comment