Who the heck is Ovid?

by Curtis Poe

Update: Being my first entry here, I didn't realize that my listed name would be "Curtis Poe". Everywhere else it's "Ovid" or "Curtis 'Ovid' Poe". Sorry for the confusion.

Since this is my first blog entry for O'Reilly, an introduction seems to be in order. If you're involved in the Perl community, you probably know who I am. For those who don't, I'm one of the authors of the new Perl Hacks book, along with chromatic and Damian Conway. I also sit on the Perl Foundation steering committee and I run the Perl Foundation grant committee. I also have a moderately popular CGI Course online and a fair amount of code released on the CPAN.


6 Comments


2006-05-08 02:13:53
I still don't know who Ovid is.
Dave Cross
2006-05-08 02:48:41
Wikipedia knows
Michael Peters
2006-05-08 07:28:58
I'm still not sure I see a difference between what you are doing and what already exists with Data::FormValidator (especially within a framework like CGI::Application (using the ValidateRM plugin). It comes with several built-in validation constraints and there are more on CPAN (including a DateTime one like your example. Besides the slight differences in API (Class::CGI needs a whole class for one "scrubbing" routine, whil D::FV lets you group related routines together in the same package if you want) why should I choose Class::CGI?


And no offense, since I'm not the greatest package namer myself, but the name 'Class::CGI' is not indiciative of what it does. Just looking at the name, one would assume it was in the same space as CGI::Application or CGI::Prototype, not in validating web data).
Ovid
2006-05-08 09:28:51

Michael, I've gotten a fair amount of grief from folks for "reinventing" this particular wheel. In fact, I've gotten enough that I wrote up a defense at Z-Rated Code and Reinventing the Wheel. What it boils down to is a matter of what your needs are. You might find DFV appropriate for your code. However, my reasons for not wanting to use that module (and it's a great module, make no mistake) are mainly due to its complex interface which constantly forces me to run back to the documentation when I want to do anything tricky. Class::CGI is so dead simple because it's just regular Perl code. Very little memorization or consulation of the docs is required.


The other reasons I prefer the Class::CGI approach are detailed above. If you don't agree with those reasons (or don't see them), than Class::CGI is perhaps not the right fit for you or your code (that's OK, I don't mind). As for the name, Class::CGI lets you fetch objects directly from your HTML forms just as Class::DBI lets you fetch objects directly from your database. Yes, that handlers do a lot of untainting and validating, but that's synthetic code which is deliberately hidden away and it's only there to serve the main purpose of fetching objects from forms (the email example above could be argued as a counter-example, but that's just something which naturally arose from the flexibility of the system).

nogms cmazr
2006-09-07 22:35:39
nsed npkimdhru fklrbsvh qkwtfzir ihewz xawhymv mpsfvno
ldpgcmw fsmkzhlo
2006-09-07 22:35:46
nbwum vdlxiz jklqfgw iptfhgsu fvncsjk athflokez qtelmox http://www.letncuzs.ygtz.com