I've been doing a lot of "Zope" and "CMF" work lately, wrapping up a couple of projects and tinkering around with our own internal project site (hence all the recent interest in Bug/Issue Trackers, of which I still don't have a satisfactory conclusion about). There's not much to say except for a fair amount of praise. Zope 2.5.1 is a pretty solid release, and the recent
new technologies that have been added to Zope, such as Page Templates, Python Scripts, and long-overdue Session management are pretty much done right. I'm not without a few complaints / desires. The one that really caught my mind today (from an annoyance that I had to bully through under tight deadline a month and a half ago) is this:
Page-Load Handlers for Page Templates
On one recent project, I had to deal with session timeout situations or situations where a user visited a page directly with no session data (their user id or shopping cart contents). The solution that worked out best for me was to just allow certain errors to happen (KeyErrors, etc), and catch that in
standard_error_message and report it as "hmm, your session has most likely expired.. Unfortunately, this could mask other errors in the system - testing found most of them, and a "session timeout" is a friendlier error message than most, but I'm still uncomfortable for the situations it may be untrue in. In DTML, it was pretty easy to add a couple of lines of code to catch the situation and raise a redirect error. In Page Templates, it's a bit trickier. And uglier.
ASP.NET has a 'Page_Load' event handler a developer could write. It can be used to prepare data for a Page, or to do preconditions. I think that Page Templates might benefit from a similar solution - add a 'Page Load Handler' field that is a TALES expression of its own. I see a fair amount of page templates that weigh themselves down with excessive TALES 'define' expressions at or near the top of a document, sometimes with funky boolean logic to try to prepare data for use later on. Attaching a Page_Load handler that could return data to add to the TALES
options context, or return a substitute page in advent of some logic succeeding/failing (ie - a session timeout) could be quite advantageous. It could also benefit situations where Response headers need to be altered. And finally - it would help the separation of Template Logic (aka "display logic") from some of the more programmatic logic that still seeps in to Page Templates from time to time. It's just a thought. There are ways around having such a handler built in, but the ones I've toyed with have proven to be fallible or tricky to maintain.