Re^5: Model-View-Controller: Template Toolkit vs. XSLT

[Corion]

I think I came across a bit harsh - I see these holes, and they need to be fixed, but I currently don't have the time/energy to fix them. Most of the complaints stem from the code as Simon wrote it, and I understand that he wrote most of the code as proof of concept. But this implies to me that more work needs to be done before one can use Maypole in a business setting. Personally, I already use Maypole for my pet project(s), but I'm not really content with the time that I spend hunting down errors.

UNIVERSAL::require eats/hides compilation errors in the required modules and does not propagate raised errors into $@, but into $UNIVERSAL::require::ERROR, a variable that is not checked and not documented anywhere - this blame goes in equal parts to Schwern who wrote it and Simon Cozens who used it.

I haven't looked at the development versions of Maypole, but for Maypole 1.7, the current CPAN version, much of the needed documentation needs to be hunted down in the Maypole Wiki and on the Maypole mailing list and can't be divined from the Pod.

My beef with the Maypole concept of creating a URL stems from an actual example - Maypole URLs look like :

/$application/$table/$action/$row_id

but in my application, a photo gallery, I want to display an image in a resolution, and the image filename and the resolution parameters come from the database. Maypole provides no nice way in which the above scheme can be conveniently expanded to take more than one table/row_id, except adding them as CGI query parameters - but then, why have the "fancy" URL in the first place?

"Wildly spewed warnings that can't be disabled" occur in Maypole::Session::AuthCookie, which has tracing/debugging warnings left enabled and fills up the logs nicely with it. I'd like something along the log levels of LWP or DBI, where you have a good granularity of what you want to see and how much of it.

I did not post these points as complaints, I see these points more as "things to be fixed" - and while I plan to work on these points, I don't have the time and energy currently. I'll join the mailing list soonish I hope, but there are also talk proposals to be written and real life to be managed ...