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

use Perl Log In

Log In

[ Create a new account ]

Ovid (2709)

Ovid
  (email not shown publicly)
http://publius-ovidius.livejournal.com/
AOL IM: ovidperl (Add Buddy, Send Message)

Stuff with the Perl Foundation. A couple of patches in the Perl core. A few CPAN modules. That about sums it up.

Journal of Ovid (2709)

Tuesday March 02, 2004
10:28 AM

Building Enterprise Level Web Applications with Maypole

[ #17716 ]

I've been hearing a bit about Maypole (think "Struts for Perl"). In a nutshell, it's designed to allow you to write complex database driven Web applications very quickly. For example, how long would it take you to build a Friendster/Orkut type web application that does the following?

  • login
  • logout
  • view users
  • browse users
  • search for users
  • edit profiles
  • mail out invites to new users
  • accept invites
  • reject invites
  • sign up new users
  • offer friend connections
  • accept friend connections

Simon Cozens writes that it took him just over a week with only 300 lines of Perl. Maypole runs under mod_perl and is available on the CPAN. It's built on top of Class::DBI, Template Toolkit, DBI and Apache::MVC.

This is something that I think Perl has long been needing. Whether or not Maypole is the way to go is not something that I can say, but I do feel that something like this would be a Good Thing for several reasons. First, my job boils down to providing maximum value for minumum cost and the less code I have to write, the fewer bugs I will create. Second, Perl has long been lacking an enterprise level Web application framework. Regardless of your views on frameworks, this has been an issue which has led many outside of the Perl community to dismiss Perl.

Maypole is being actively developed, it has a mailing list and, with Simon Cozens being behind it, I think it has a chance to go far so long as people get behind it. It's also being built on top of solid, proven technologies.

Any thoughts? Are there problems with his approach? Are there competitors worth checking out?


List all Journal entries
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.