Slash Boxes
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

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • The "order_date" would be handled by expecting parameters named "order_day", "order_month" and "order_year". How this is done internally is an example in the Class::CGI docs.

    Danger Will Robinson!

    I did that too. It hurt.

    It was after the second rewrite that I finally ended up with that namespacing and dot-seperators thing.


    order_date => 'Class::CGI::DateTime', ... should not break out of "order_date".

    Rather, what works really well is that it expects, order_date.month, order_date.year fields, and you use something like CGI::Tree to hand Class::CGI::DateTime constructor param of { day => 1, month => 2, year => 3 }.

    It makes things really clean, because then Class::CGI doesn't need to care about the actual namespace, it just gets the information it cares about.

    And once you get to profile classes, then you can do the same thing., profile.order_date.month, etc
    • First, what is CGI::Tree? I couldn't find that.

      Second, I've deliberately adopted an approach which fits parameter names I'm seeing in most forms. I do admit that what you're doing is cleaner, but it's not what folks in forms seem to be doing. However, your approach does seem to be very workable. I'll think about it.

      Out of curiosity, why haven't you released any of that to the CPAN, or did I just not see it in your slough of modules?

      • Sorry, I got "CGI::Tree" from memory, I'll find you the proper name later.

        The reason I never released my stuff to CPAN was because it was too integrated into my AppSpace project to be able to break it out properly.

        It used a MetaModel (think something a bit like a Moose model) to do both the Class::DBI-like stuff, and the Class::CGI-like stuff. And because it was using MetaModel data to control the widgets, it would have been very difficult to get it out.

        Plus I screwed up in that the entire project had a dyn
    • I might addt that here's one way to support your dot syntax:

      package My::Handler::DateTime;
      use DateTime;

      sub new {
          my ($class, $cgi, $param) = @_;
          my @params = qw(day month year);
          if ('date' ne $param) {
              @params = map { "$param.$_" } @params;
          my ($day, $month, $year) = map { $cgi->raw_param($_) } @params;
          return DateTime->new(
              day   => $day,

    • order_date => 'Class::CGI::DateTime' should not break out of “order_date”.

      Did you actually look at Class::CGI? It has no conventions whatsoever regarding parameter naming. You can do your beloved dot-based namespaces just as well as someone else can choose not to. Given order_date, it is entirely up to Class::CGI::DateTime to decide whether it wants to consume qw( order_year order_month order_day ) or qw( order_date.year order_date.month ).

      • You sound bitter.

        Certainly it is up to order_date what it wants to consume.

        Just as it's up to Class::CGI whether it wants to use Class::DBI as well, or up to Class::CGI::DateTime if it wants to spread it's code around into Class::CGI::TextBox and Class::CGI::DropBox.

        Except that although you can do this, you shouldn't.

        If you have n Class::CGI objects on a page, how do you share out the names? It naturally becomes a namespace, just as Perl uses namespace. That it is a dot is a matter of personal preference, i
        • I’m not arguing about the merit of namespaces or of employing them. I’m saying that these issues are orthogonal (and hence irrelevant) to Class::CGI’s interface, so there’s no need to keep harping on them. This is the third time you brought it up – it’s okay, we got it. That’s all; no bitterness.