On Thu, 4 Jan 2001 19:48:53 -0800 (PST)
Bob Sidebotham <[EMAIL PROTECTED]> wrote:
> --- Somebody wrote:
> > > Of course, the best solution would be for the 'magic'
> lookup to be
> > > optional...
> Alright, I've not a zope master, but isn't this already
> generically with:
> <dtml-with SESSION only>
> All these arguments leave me a little confused: As a
> newbie, I read the
> zope book, and it tells me all these wonderful things
> about feeding
> alligators with ostriches, and the like, and I assume
> this is meant to
> be universal, and just assume that all names are supposed
> to behave in
> this manner. But Chris seems to be saying that *because
> you've had
> flack about this model* maybe a new feature shouldn't use
> it. Forgive
> me if I'm paraphrasing you incorrectly. So the question I
> have is
> this--if there's a basic problem with zope's acquisition
> semantics (as
> some posts on this list would indicate at least some
> people believe),
> then is the right fix for new features to avoid
> acquisition, or would
> it be better to figure out what is good and what is bad
> and bite the
> bullet and get rid of the bad?
A deeper look at how Zope makes use of acquisition is on the
plate for future development... there's been talks at DC
about in a major future revision making acquisition explicit
by default instead of the current situation where
acquisition is implicit by default.
Til then, we need to work with what we've got. ;-)
> Chris keeps saying that it would be hard to explain the
> semantics. But
> if zope is worth learning, shouldn't these semantics be
> totally generically? Why should they have to be
> separately documented
> just for session variables? What is really special about
> variables (other than that they can be written to)?
Nothing. It's a new feature, and hopefully I'd be doing the
right thing to make its semantics more explicit for a
> As an aside, how did zope even get this far without
> session variables?
> I'm very confused...
There are other good sessioning Products available:
FSSession, SQLSession, HappySession come to mind. These are
great, but we need something that will work across ZEO
clients that doesn't require a relational database backend.
Thus the coresessiontracking stuff...
> And finally, *even* if the session variables are kept in
> a private
> space, I'd at least like some way to make them public
> using some
> generic pre-processing.
I think the idiom here will be:
<dtml-with "datamgr.getSessionData()" mapping>
> But I don't see how to do that,
> because if I
> stick a dtml-with, for instance, into generic header code
> for example, by standard-html-header, then this with
> statement is
> required to be *closed* when I edit it).
Yeah, the split between header and footer is unfortunate
right now... one way to have the stuff available in all
your documents would be to use the request namespace in the
<dtml-call "REQUEST.set(data, 'sessiondata')">
...then in the rest of your documents, you could refer to
This is not particularly encouraged. Hopefully the upcoming
HiperDOM will solve the header/footer split problem.
Zope maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -