[ZPT] Page Template Preconditions?
jeffrey
jeffrey@cuemedia.com
Mon, 12 Aug 2002 16:51:59 GMT
Jim Fulton writes:
> Evan Simpson wrote:
> > Jeffrey P Shell wrote:
> >
> >> So then I tried doing a <..tal:define="dummy
> >> python:here.checkSession(...)">, but in any combination I tried the
> >> redirect
> >> never happened - raising one just brought up TALESError, and I think a
> >> 'RESPONSE.redirect(...)' call just got swallowed.
> >
> >
> > These should both work :-(
>
> I wonder why they didn't. This doesn't seem like it should be
> hard to do.
I lied. "raise 'redirect', ..." from a Python script called in a
tal:define statement becomes a TALESError. If that same Python scrip calls
RESPONSE.redirect, it usually works. (I say 'usually' because I ran into
some problems (which I haven't been able to reproduce) with
response.redirect in Python Scripts. I'll elaborate on this later when I
have some harder data).
> > I have developed a pattern for pages that require a lot of prep work
> > (especially form/wizard participants) that involves directing all
> > requests to a Script. The Script does the prep, then usually ends with
> > a 'return container['scriptname.pt'](somedata=somedata)'.
>
>
> I have a similar pattern, except, I usually have a single define
> at the top of the template that calls a Python method that computes
> a data structure containing the things I need.
I think I got squeamish about when using a page-wide macro in the <html>
tag itself, where such a define call should be put. I was under deadline
and didn't spend enough time investigating the behaviors of metal:use-macro
in the same tag with a tal:define (I was worried that the tal:define would
get eaten by the Macro).
> > It would certainly be possible to add a 'pre-publish' field to ZPT, with
> > the value interpreted as a TALES expression. I would expect this to be
> > evaluated only when the ZPT is being published directly, not when it's
> > called from other code. The only questions remaining in my mind would
> > be how to best make the ZPT object available to the Script (if the
> > expression calls a Script) and how to interpret the value of the
> > expression. If the expression evaluates to a tuple, list, or mapping,
> > it would be straightforward to place in 'options'. It might be helpful
> > to interpret a string as "publish this instead of the template". What
> > about other values?
>
> This all sounds too complicated to me. Surely, we don't need this.
Other web servers that are object oriented (or at least - object/event
based) have the notion of a page-load / awake event. I guess Zope does too
with its traversal hooks. It just think it would be nice to expose some
level of event handling for things like page-loading as Zope moves in that
direction.
It's not a critical need, but I think it would be a nicety.
--
Jeffrey Shell