Maypole: a perl MVC framework   (link)

http://maypole.perl.org/
http://www-106.ibm.com/developerworks/linux/library/l-maypole/?ca=dgr-perlw02BuildMypole
http://search.cpan.org/~simonflk/Maypole/
The development of my latest project, Maypole, began over 4000 years ago, when, so the story goes, the goddess Ninkasi taught the Sumerian mortals a recipe for a magical drink. Her concoction of hops, barley, yeast, and water (and a few other special ingredients), was an instant hit, and has remained the cornerstone of a university education ever since.

Not one to do things by halves (or should that be 284 ml?), what started as a simple database ended up as a complete framework for writing Web-based, database-backed applications in Perl.

http://perlmonks.thepen.com/388607.html
When I first caught eye of Maypole, I was startled by the shining beauty and the effortless grace with which it seemed to produce shiny web applications. I envied those who had a firm grasp of it and strived to employ Maypole to collect and publish the data available to me. But in that time, Maypole was a very immature Primadonna with very specific needs that were only faintly hinted at on websites only known to a few select people already in the clique. Armed with my knowledge of Class::DBI and frugal knowledge of mod_perl, I found myself rejected by Maypole and its requirements often for no reason apparent to me and loudly complained about this in the chatterbox, to the bemusement and annoyance of the other regulars there, I assume. After all, Maypole had been touted as the web application framework, being hawked through articles like flowers on the 14th of February and had received real money from the Perl Foundation. I felt I had a right to it.

http://perlmonks.thepen.com/433729.html
survey of surveys on perl-based html templating systems

http://search.cpan.org/~simon/Rubberband-0.01/lib/Rubberband.pm
Rubberband, as its name implies, is designed to be stretched in both directions. It uses Module::Pluggable::Ordered to locate the classes which encapsulate the tables, and also to provide a callback functionality to allow extensions to "talk" to each other; it also uses Class::DBI::DATA::Schema to allow extension classes to declare the SQL to set up their tables. Further, it helps to set up your classes by creating a backend Foo::DBI class (given an application called Foo, of course...) which handles the connection information, and from which your plugin modules automatically inherit.