Simon and Henrietta Cozens

So, the details of the Maypole project. Let me start by saying that the plan was always for Apache::MVC to be abstracted into a more general MVC web application framework, and so Apache::MVC would eventually become the Apache-based subclass of this more general project. And such projects need a name - Struts, Brazil, Quixote, Wafer, and so on.

Also, having a name like that allows the project to have a decent web presence, show up on people's CVs, and so on. I really do see Maypole as being Struts for Perl programmers. (Without XML taglibs, of course, because XSP has given me insane amounts of grief in the past.)

So why Maypole? I wanted a name which reflected the fact that the framework was a focal point for various different "strands"; that in a sense it tied everything together. I got thinking about knots and anchors and things but that wasn't helpful.

In the same way that a maypole is nothing special by itself, but needs dancers around it, Maypole isn't really very interesting on its own but works wonderfully when combined with a data source library, a view layer and a presentation mechanism. Equally, though, you can't have a maypole dance without the maypole.

What does this mean for Apache::MVC users? Not very much. The Apache::MVC distribution will still exist and do exactly what it does at the moment. Your code will still work. However, Apache::MVC itself will become a subclass of Maypole.pm, the core libraries Apache::MVC::View::TT and Apache::MVC::Model::CDBI will become Maypole::View::TT and Maypole::Model::CDBI. Your model-derived classes (BeerDB::Brewery and friends) will now (I say now, but I haven't actually refactored the code yet) inherit from Maypole::Model::CDBI, but this will be completely transparent. The only people who will be affected will be those hacking on the core Apache::MVC code - i.e. me.