[ZPT] Page Template Preconditions?

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