|No such thing as a small change|
Re^3: RFC: Class::CGIby rhesa (Vicar)
|on Apr 08, 2006 at 19:54 UTC||Need Help??|
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.
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.What I was saying a little further down, is that I can put that logic inside My::Customer, where it belongs (in my opinion):
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:
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.