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?
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?
Re:Maypole. . .
Ovid on 2004-03-02T16:41:28
I also posted this to Perlmonks and Apache::PageKit 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 download in CSV or similar formats.
Re:Maypole. . .
perrin on 2004-03-02T23:17:17
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.
There are almost certainly more differences, but I have a non-Perl day job to get back to
Re:OpenInteract comparison
Simon on 2004-03-02T22:13:54
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 Maypole could actually do the complex things relatively easily. But OI2 is certainly bigger and chunkier, and possibly better suited to more environments - Maypole is meant to be sleek and generic, and I hope I've designed it well enough to be generic but it hasn't been stressed in as many environments as OI2 yet.
OI2 is very big.That's because you have documentation, you cheat!
:) As a result you need to do more work to startup a new system, although the quick start guide [sourceforge.net] helps out with that.Yeah. I wanted Maypole initially so that I could run up really really quick interfaces to databases. The fact that it does more is a bonus. I'm a big fan of obviating as much code as possible and generally doing what the user means. As you say, there's always a trade-off for that and Maypole and OI2 sit at different ends of the scale.
Both rely on the Template Toolkit, although OI2 supports additional content generation methodsMaypole does too, but the Template Toolkit is Too Damned Good so nobody's written any other View classes yet.
:) Both are tied to an object-relational mapping solution -- OI2 uses SPOPS while Maypole uses Class::DBI. But I think both can use other solutions without too much problem (that is, using SPOPS objects in Maypole and Class::DBI objects in OI2).Yep.
Class::DBI is generally simpler than SPOPS but SPOPS also does LDAP and some mildly interesting stuff with security.There's your simplicity-functionality tradeoff again.
So in Maypole you map a URL to an action (represented by a PerlHandler) using Apache. In OI2 a package (or distributable application) contains an 'action.ini' file which registers classes (and optional parameters) with the framework and tells it what names it will respond to. Another component is responsible for mapping incoming URLs to names.Yeah. Now you can override the mapping method in Maypole - or indeed any of the methods - but it's intended to give you sensible defaults that do what you mean. In fact, the mapping method isn't in Maypole at all - it's in Apache::MVC.
You also declare if an action is secured, what methods are not allowed, and more.Maypole does this with attributes, which is quirky but fun.
In fact comparing the beer DB example from Simon's weblog entry to the OI2 package development tutorial [sourceforge.net] is pretty usefulThere's a much longer Maypole article coming out on DeveloperWorks soon, hopefully, which not only talks about simple stuff like the BeerDB, but also how I put together Flox.
You can use OI2 under multiple environments. Currently Apache 1.x, CGI and LWP are supported, with a working (but probably suboptimal) version using Apache 2.x in the next beta.Again, you got there first, and nobody's implemented the front-end classes for Maypole yet. That said, I got some patches to support Apache 2, and so there'll probably be a CGI::Maypole coming out this Thursday.
OI2 focuses on creating distributable, standalone applications.*nod*. Maypole doesn't touch this.
I think the application server problemspace is sufficently complex that having multiple solutions are extremely useful.No quibbles there.
Re:OpenInteract comparison
lachoy on 2004-03-03T03:45:16
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!
Re:OpenInteract comparison
Ovid on 2004-03-03T06:02:08
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
: die "Do not call me in void context";
}Doing that for several subroutines can get tedious. One alternative is to use attributes (via Attribute::Context).
use base 'Attribute::Context';
sub foo : Arrayref(NOVOID) {
# do stuff
return @array;
}No muss, no fuss. You just specify what happens depending upon the context in which something is called. Attributes are really quite nifty once you get used to them.
Re:OpenInteract comparison
lachoy on 2004-03-03T12:11:39
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
:-)
