Beefy Boxes and Bandwidth Generously Provided by pair Networks
Think about Loose Coupling

Re^3: RFC: Class::CGI

by rhesa (Vicar)
on Apr 08, 2006 at 19:54 UTC ( #542069=note: print w/replies, xml ) Need Help??

in reply to Re^2: RFC: Class::CGI
in thread RFC: Class::CGI

Ok, I'm throwing in the towel :)

It wasn't my intention to champion DFV in the first place; you obviously have an itch to scratch; I know you write good code; and I suppose every module promoting safe CGI processing is a good one.

I still have the feeling you're reinventing a wheel for which there already is a perfectly adequate implementation, but in the end, it's not my place to dissuade you from doing that.

Good luck!

I'm writing this as much for my own benefit (in order to better understand DFV) as for clarifying some of the technical points above. It's not intended to persuade anyone one way or the other.
... and you force me to implement the logic in new(). That would prevent me from putting the logic in my object itself.

I don't get what you're saying. Look at your counter-example...

What I was saying a little further down, is that I can put that logic inside My::Customer, where it belongs (in my opinion):
# DFV profile: constraints => { customer_name => My::Customer->from_cgi }

# object implementation package My::Customer; sub from_cgi { my $pkg = shift; return { params => [ qw/ customer_name email age / ], constraint => sub { my ($name, $email, $age) = @_; # untaint, trim, whatever return $pkg->find_or_create( ... ); } }; }

In other words, in this form you and I are pretty much doing the exact same thing. We're both asking the developer to follow certain conventions. The main differences are:

  1. I don't require a separate Handler object
  2. I don't require the use of new() as method
  3. I still have the freedom to use the DFV features directly
  4. (i admit...) my handler code looks weird

In terms of learning curve for the end-user, I think both approaches are about the same. In your case, the developer needs to know to specify My::SomeObject::Handler, which wraps a constructor to get a SomeObject instance. In my case, the developer needs to know which method in SomeObject can construct the object from cgi.

I do appreciate your objections against DFV (lots of docs searching); and I do agree that your code looks much cleaner than vanilla DFV. But everything I've written sofar I have been able to glean from the docs and the source in about an hour, and I am not a regular user of DFV (except that I haven't actually tested it, so I'm not 100% sure it really works).

I also see room for writing a subclass of or wrapper around DFV that could make my from_cgi() implementation even simpler (by imposing certain conventions), and expose roughly the same interface to the end-user as your Class::CGI. If I did that -- and I'm getting excited about it for my in-house projects -- I still have the option to expose the raw features of DFV.

Ovid, please don't take any of this too seriously. I'm not attacking you of course, and I certainly don't want to stop you from writing Class::CGI. In fact, I'm not even sure why I'm rambling on so much -- that's not usual for me at all. What I think is that you've triggered something in me that made me realise the value in actually wrapping the tedious cgi processing -- something I've not been able to introduce at $work until now. And that is probably because DFV is very verbose out-of-the-box.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://542069]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others lurking in the Monastery: (6)
As of 2017-09-24 12:52 GMT
Find Nodes?
    Voting Booth?
    During the recent solar eclipse, I:

    Results (274 votes). Check out past polls.