You're assuming that programmers are one dimensional. There are quite a few of us who didn't come to programming directly, but through other directions. I personally got into Perl after the only programmer in our web development group (well, we named our group 'Custom Research And Programming', but management didn't like the acronym) left, and I had to maintain and develop his code.

I got into the group because I had graphics experience. I've been writing HTML for a decade now. I'm guessing that other programmers could write nice looking templates, as well.

I'd personally rather have something that's easy to develop to and maintain. I couldn't care less about the shiny packaging -- I'd rather have something simple and elegent, which I know I can easily write myself.

I will agree that there are those people that aren't so good at the design aspects, just as there are good designers that can't code. But there are folks who can do more than just one thing. I may not be the best programmer, or the best designer, but I can get by in both aspects.

I will agree that the reason to use templating systems is to save time -- and that some people will derive more savings than others in not having to develop their own look and feel. But likewise, there are those people who would gain more from having a well written template engine, especially if it's easy to learn the syntax so they can adapt their existing design.

Similar story : years ago, before MMORPGs, a group of my friends decided that there were two main types of people who write for MUDs -- the ones who like doing programming, and the ones who like being creative. We starting building templating systems and a library of reusable objects/monsters/etc, but well, we never got it finished the point to turn it over to the creative folks. (mostly my fault, for deciding to re-write the combat system). We went with a similar premise to yours, but we had two general categories of users, not just one. (and we accepted the possibility that people might fit into both, and would be able to add stuff outside of the virtualization engine.

I am thinking now about rewriting my app in Catalyst, but frankly I can't get the C::Model::CDBI::CRUD working, so I think I'll wait a bit untill most of the framework works. It look promising in that it seems to be much more flexible than Maypole (and they say it's faster too), but currently it lacks the scaffolding that Maypole provides. I believe in incremental development and with CRUD you can get your app quickly, even if not in the shape you really wanted it, but then you can refine it.

The plus for Catalyst is that it seems to be moving fast, at least now.

Could you tell us more? This interests me the most, because I'm considering using Maypole for a couple of things.

For projects I was considering, Maypole commits too much to a particular strategy. I've found frameworks like that to be very great to get something started, but almost everyone wants to tweak something (especially customers, and at random times, and always urgent), and Maypole didn't look like it could "slide laterally" very well.

That's actually why I wrote CGI::Prototype - to try to get the framework out of the way, yet have a nice framework where I'd have a place to write each thing once.

-- Randal L. Schwartz, Perl hacker
Be sure to read my standard disclaimer if this is a reply.

Maypole is designed to have some CRUD (CReate, Update, Delete) database web app very quick. And it is good at that. If your app fits that model well than you have saved lot's of time if not you will have to spend a lot of time to add the missing functionality. I thought that CRUD could quite flexible if you were allowed to use database views but first views were not supported by the Maypole libraries (I eventually got it working with some patches with Postgresql), second it still is not that flexible as I thought.

And the last point the paging is not done right - at last in search, I remember, all the data is fetched first from the database and only then the items for the current page are filtered. So if you have in your database hundreds of thousends of records you'll have all of them in the memory in one huge array only to filter then a few of them.

I remember, all the data is fetched first from the database and only then the items for the current page are filtered. So if you have in your database hundreds of thousends of records you'll have all of them in the memory in one huge array only to filter then a few of them.

This is a problem with Class::DBI, not Maypole. Class::DBI::Iterator fetches all the data and stores it as an array, as opposed to wrapping the underlying DBI statement handle.

-sam

As the author emeritus of Maypole (Simon Cozens) has said one more than one occasion the templates that are packaged with Maypole are meant for example purposes only and you're not actually supposed to use them (I didn't).

I've been using Maypole for some time now and settled on it after looking at several other web frameworks. Maypole won out for several reasons:

It doesn't try to be everything to everyone. I have built several web applications of varying complexity with different technologies (Siebel, LAM/Perl/PHP, etc.) and have discovered that framework-enabled functionality often gets in the way of properly solving the problems at hand. No number framework developers can forsee and appropriately address all of the problems you're likely to encounter when developing large scale web applications and thus their implementations are often likely to be inaccurate or misused at best. Small frameworks are often best for building small-to-medium sized applications and should seek to provide a basis for implementing a solution but not seek to be the solution.

Secondly, the usefulness of a framework is inversely proportional the level of abstraction. Abstraction is nice but the harder you try to be everything to everyone (see above) the quicker you'll discover that your framework accomplishes little particularly well, with the exception of providing more avenues for half-assed extensions. The phrase "Jack of all trades, master of none" applies particularly well here. Yes, there are several components of Maypole than can be replaced but it works best as it is (i.e. before Simon gave control of it to the hordes).

It is my view that although nicely formatted and well thought out templates are nice, they cannot replace poorly thought-out design. As the templates provided for Maypole are meant to be throw-away examples, I think your thesis as it applies to Maypole is moot and probably for other frameworks as well (although I'm willing to admit that I'm wrong about this assumption). After all, what good is your framework if you have to re-write half of it to suit your needs.

The fact that Simon has to constantly remind people to not use the templates is only supporting my point that templates are important for programmers. And it is not the first time when the author did not envisage how people will use his own creation.