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

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Building Enterprise Level Web Applications with Maypole 9 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • . . .seems very promising to me. Being in the middle of such an app as you describe, this could have been a real timesaver. I'll definitely be checking it out.

    It seems to be, in some ways, CGI::Application on steroids. Using CGI::Application has bought me some flexibility that I might not have with Maypole, but like you said, a consistent, enterprise-class framework is something that Perl could really use.

    Thanks for bringing this to my attention :) This will get added to my growing list of things to c

    • I also posted this to Perlmonks [perlmonks.org] and Apache::PageKit [cpan.org] has been brought to my attention. It appear to have been around quite a bit longer, but I don't know enough about it to know how to compare and contrast the two. The only thing that stood out right away is that PageKit uses HTML::Template. That's a great module, but I've been seduced by the power of Template Toolkit. With TT, I'm not restricted to HTML. I can output data in many different formats. This would be great for creating automatic report dow

      • Actually, HTML::Template is not restricted to HTML. It can be used for any text-based templating problem. I've used it for e-mail.
  • It sounds to me like a reinvention of SPOPS/OpenInteract, which is a mature and slowly-developing project. I wonder if the distinctions are worth the redundant overlaps.
    --
    • Randal L. Schwartz
    • Stonehenge
  • I haven't taken a detailed look at Maypole yet (no tuits), but just off the top of my head there are a number of similarities between Maypole and OpenInteract (I'll focus on the still-in-beta OpenInteract2 because it's got a lot more going for it). Generally OI2 is much more heavyweight and designed to adapt to more environments than Maypole. But that doesn't mean it's better -- as usual flexibility comes at a price, in this case complexity. And as usual whether this complexity is worth it really depends on
    • On the whole, I agree with Chris! However...

      Generally OI2 is much more heavyweight and designed to adapt to more environments than Maypole. But that doesn't mean it's better -- as usual flexibility comes at a price, in this case complexity. And as usual whether this complexity is worth it really depends on what you're doing.

      True. Maypole aims to be as simple as possible, while still enabling you to do the complex things if you need to. The Orkut-alike was designed basically as a test to make sure May

      • Maypole does this with attributes, which is quirky but fun.

        That's an interesting idea. For some reason attributes always seem a little peek-a-boo to me, but that's probably because I haven't hung out with them enough.

        One of the more obvious comparisons I forgot: Maypole has a much better name than OpenInteract!

        • What do you mean by "peek-a-boo"? If handled properly, they can provide elegant solutions. For example, what if you want your subroutine to return a list in list context, a reference to an array in scalar context and die if called in void context? You might write this:

          sub foo {
              # do stuff
              return wantarray
                  ? @array
                  : defined wantarray
                      ? \@array
                     

          • I understand what attributes are, it's just that they have a fairly large potential for misuse. (Then again, so does Perl...) I agree that they can be extremely elegant and the example you gave is great, but often they're used for application-level behavior like security, web services, etc. I have a suspicion (perhaps unfounded) that it's better and easier to maintain to have this behavior external to the code so it can be modified externally.

            But I'm probably concerned over nothing :-)

Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.