On Thu, 4 Jan 2001 19:48:53 -0800 (PST) Bob Sidebotham <bob_sidebotham@yahoo.com> 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 provided generically with:

<dtml-with SESSION only>

Yes...

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 explainable totally generically? Why should they have to be separately documented just for session variables? What is really special about session 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 learnability perspective.

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> <dtml-var foo> </dtml-with>

But I don't see how to do that, because if I stick a dtml-with, for instance, into generic header code (included, 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 header: <dtml-let data=sessiondatamgr.getSessionData()"> <dtml-call "REQUEST.set(data, 'sessiondata')"> </dtml-let> ...then in the rest of your documents, you could refer to sessiondata: <dtml-let data="REQUEST['sessiondata']"> .... </dtml-let> This is not particularly encouraged. Hopefully the upcoming HiperDOM will solve the header/footer split problem.