Re: [Zope] Core Session Tracking kudos namespaces
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 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. ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Core Session Tracking kudos namespaces
"Chris McDonough" [EMAIL PROTECTED] wrote snip 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. I think a cleaner near-term workaround is to have the standard header explicitly copy all the session key-variable pairs into REQUEST.other: dtml-in "sessiondatamgr.getSessionData().items()" dtml-let k=sequence-key v=sequence-value dtml-call "REQUEST.set( k, v )" /dtml-let /dtml-in (This presumes that the getSessionData() return value supplies an items() method, which I haven't actually checked). Tres. -- === Tres Seaver[EMAIL PROTECTED] Digital Creations "Zope Dealers" http://www.zope.org ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Core Session Tracking kudos namespaces
Chris McDonough wrote: So the question becomes: do we want DTML namespace lookup magic or no DTML namespace lookup magic for names that we attempt to look up in a session data object? I don't know the answer. I'm so sick of magic at this point that I'm apt to vote "no", but if it affords us some provable real-world benefits, I could change this vote. If someone would be kind enough to give me an example where having DTML namespace lookup magic for names out of a session data object would be very useful, I'd consider it carefully. Well, if you want to get something from the session, but it might not be there and you want to fall back to somethign that was submitted on the form or, more likely, is a property of some other object and hence acquirable. Of course, the best solution would be for the 'magic' lookup to be optional... cheers, Chris ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Core Session Tracking kudos namespaces
- Original Message - From: "Chris Withers" [EMAIL PROTECTED] To: "Chris McDonough" [EMAIL PROTECTED] Cc: "Dieter Maurer" [EMAIL PROTECTED]; "Bob Sidebotham" [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, January 04, 2001 9:57 AM Subject: Re: [Zope] Core Session Tracking kudos namespaces Chris McDonough wrote: So the question becomes: do we want DTML namespace lookup magic or no DTML namespace lookup magic for names that we attempt to look up in a session data object? I don't know the answer. I'm so sick of magic at this point that I'm apt to vote "no", but if it affords us some provable real-world benefits, I could change this vote. If someone would be kind enough to give me an example where having DTML namespace lookup magic for names out of a session data object would be very useful, I'd consider it carefully. Well, if you want to get something from the session, but it might not be there and you want to fall back to somethign that was submitted on the form or, more likely, is a property of some other object and hence acquirable. seconded. This would come in most handy right now for me. Of course, the best solution would be for the 'magic' lookup to be optional... That'd also be cool. cheers, Chris ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev ) ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Core Session Tracking kudos namespaces
Chris McDonough writes: So the question becomes: do we want DTML namespace lookup magic or no DTML namespace lookup magic for names that we attempt to look up in a session data object? Maybe, we do not want the magic automatically but have a simple way to call for it, when we like. I think exposing the SessionData keys as attributes (in addition to exposing them as mapping keys) is a good thing. It allows to use: dtml- expr="... sessionData.a ..." as well as dtml-with sessionData dtml-var a /dtml-with i.e. place them in the DTML namespace, if we think they should go there. As said in an earlier message, it would be possible to bring them in the DTML namespace, if they would implement Python's mapping interface. In this case, we could use dtml-with sessionData mapping dtml-var a /dtml-with We now use "FSSession" which implements the full Python mapping interface. We can use dtml-with FSSession mapping, if we think this is good. Usually, however, we put all relevant session data into REQUEST.form and REQUEST.other in setup code and allow the main code not to worry about session handling at all. Dieter ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Core Session Tracking kudos namespaces
--- 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 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? 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)? As an aside, how did zope even get this far without session variables? I'm very confused... 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. 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). That is, I think the dtml-with has to be paired, in the header, with a /dtml-with. What Zen am I missing here? How do you guys do this sort of thing? No doubt most of the above is due to newbie confusion, not due to design issues in zope... Bob __ Do You Yahoo!? Yahoo! Photos - Share your holiday photos online! http://photos.yahoo.com/ ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Core Session Tracking kudos namespaces
--- Chris McDonough [EMAIL PROTECTED] wrote: I sympathize with the need to convert all your scripts over to use sessioning from hidden form-field encoding and the like... I'd really appreciate some input as to what kinds of problems you're trying to solve with sessioning. I don't have any great number of scripts to convert. I've only been looking at zope for a few weeks. I DO have a significant application that handles a customer database, supplier ordering, inventory management and the like. This is currently written in Perl/cgi, and is way too slow and cumbersome. I'd like to move it into zope and at the same time make the database directly available to customers. In the current implementation of the application I maintain a lot of state at the server side--the server knows the page history, locally configured options, and the like. In that application I actually force you to use server-side navigation, since I load over the existing page every time you make a request (so there is only one page ever resident in the browser). I did this to make it impossible for the operator to use an old browser page (with stale form info). This is ugly and requires two round-trips for each request. I'm trying to figure out how to move this into zope, and to do this in the most natural way possible. So I'd like to give up mostly on the server-side navigation stuff. But I do want to do things like: if you go from a main page to a form, then if the form succeeds I'd like to return you directly to the main page (with no extra page fetch). If the form fails, it might go back to the main page, or include the error somewhere in the main page. Since the form is likely to be unrelated to the main page (just linked to from it), I need at least some server state to tell me where to return. I can also imagine doing side trips from forms--but that's harder, because then the side trip can't involve a link, otherwise you lose the information typed in (I "solved" this in my current implementation by wrapping *every* page in one big form and making all the links actually do submits, using a little javascript, but again that's something I'd rather avoid--I'd rather it was simple and relatively unsurprising). I'm unclear as to how I should really implement any of this. It almost seems like there is some sort of abstraction here that can be turned into a generic facility, but I haven't groked zope enough to figure out how that would be plugged in and what it would look like. So anyway, this was supposed to be an answer to your question, but it's really a thinly disguised attempt to get some design help on this. Is there another forum purely for design help with this sort of thing? How to fit a particular navigational abstraction into the zope framework? Thanks, Bob __ Do You Yahoo!? Yahoo! Photos - Share your holiday photos online! http://photos.yahoo.com/ ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Core Session Tracking kudos namespaces
Chris McDonough writes: Currently, nothing would be acquired, and the dtml-var a call will fail inside of a "with sessiondatamanager" even if we did have a __getattr__ interface to session data objects Are you sure? As I understand it, at least a dtml-with "sessionDataManager.getSessionData()" would make available all session data keys as variables, if they had a "__getattr__". If they had a "__getitem__" (maybe, the available "get" is already sufficient), then dtml-with "sessionDataManager.getSessionData()" mapping would do the trick. Dieter ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Core Session Tracking kudos namespaces
You're right, Dieter. I was thinking in Python terms and forgot about DTML namespace lookup rules. :-( Yes, if we had a __getattr__ interface or used the mapping keyword on the return value of a __getitem__-based session data object, and if the name was not found in the namespace that is put on the DTML stack by "with sessiondataobject", it would then be looked up in the form and cookies namespaces, then it would attempt to be acquired, etc. Sorry for the misinformation. So the question becomes: do we want DTML namespace lookup magic or no DTML namespace lookup magic for names that we attempt to look up in a session data object? I don't know the answer. I'm so sick of magic at this point that I'm apt to vote "no", but if it affords us some provable real-world benefits, I could change this vote. If someone would be kind enough to give me an example where having DTML namespace lookup magic for names out of a session data object would be very useful, I'd consider it carefully. - Original Message - From: "Dieter Maurer" [EMAIL PROTECTED] To: "Chris McDonough" [EMAIL PROTECTED] Cc: "Bob Sidebotham" [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, January 03, 2001 4:50 PM Subject: Re: [Zope] Core Session Tracking kudos namespaces Chris McDonough writes: Currently, nothing would be acquired, and the dtml-var a call will fail inside of a "with sessiondatamanager" even if we did have a __getattr__ interface to session data objects Are you sure? As I understand it, at least a dtml-with "sessionDataManager.getSessionData()" would make available all session data keys as variables, if they had a "__getattr__". If they had a "__getitem__" (maybe, the available "get" is already sufficient), then dtml-with "sessionDataManager.getSessionData()" mapping would do the trick. Dieter ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev ) ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
[Zope] Core Session Tracking kudos namespaces
1. The Core Session Tracking looks like it will be really helpful. I AM BLOWN AWAY BY THE QUALITY OF THE DOCUMENTATION. Congratulations for making really readable, easy to use installation and use instructions. Part of the reason I'm so blown away, of course, is that the quality of this documentation is so very much superior to most of the existing documentation. The author obviously put himself in the position of someone who didn't know anything about the topic, and wrote the documentation to satisfy this person (i.e. me). Thanks! 2. Question. The interface to the session data object, requiring set/get calls to get key/value pairs seems a little inconsistent with the very simple existing interfaces for other zope namespaces. As a newbie, I admit to being very confused about namespaces in zope, and the GOOD THING about the core session tracking is that it is very clear that you're accessing a variable from that scope. There's no way you can accidently acquire something else. On the other hand, the ability to access the session variables with simple variable references seems like it would be a win (especially if they were safely qualified by the session object). I really just want to do something like "SESSION.varname". Is this something that can be wrapped on top of the existing interface? Bob Sidebotham [EMAIL PROTECTED] __ Do You Yahoo!? Yahoo! Photos - Share your holiday photos online! http://photos.yahoo.com/ ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Core Session Tracking kudos namespaces
1. The Core Session Tracking looks like it will be really helpful. I AM
BLOWN AWAY BY THE QUALITY OF THE DOCUMENTATION. Congratulations for
making really readable, easy to use installation and use instructions.
Part of the reason I'm so blown away, of course, is that the quality of
this documentation is so very much superior to most of the existing
documentation. The author obviously put himself in the position of
someone who didn't know anything about the topic, and wrote the
documentation to satisfy this person (i.e. me). Thanks!
Thanks for the kudos!
2. Question. The interface to the session data object, requiring
set/get calls to get key/value pairs seems a little inconsistent with
the very simple existing interfaces for other zope namespaces. As a
newbie, I admit to being very confused about namespaces in zope, and
the GOOD THING about the core session tracking is that it is very clear
that you're accessing a variable from that scope. There's no way you
can accidently acquire something else. On the other hand, the ability
to access the session variables with simple variable references seems
like it would be a win (especially if they were safely qualified by the
session object). I really just want to do something like
"SESSION.varname". Is this something that can be wrapped on top of the
existing interface?
Yes. I will think about this, because I'm not very happy about the current
data object interface. It definitely needs work.
I had orignally intended to use a straight mapping (dictionary) interface,
but we've got a lot of DTML code that looks like "_[[['']]]" already, so I
didn't want to perpetuate the problem by encouraging __getitem__ and
__setitem__ access in DTML. :-) That's why you can't do SESSION['varname']
right now, and instead you need to use SESSION.get('varname'). This lends
itself better to things like:
dtml-with sessionmanager
dtml-with getSessionData
dtml-var "get('a')"
/dtml-with
/dtml-with
which potentially has the same rhythm as
dtml-with sessionmanager
dtml-with getSessionData
dtml-call "set('a', 'b')"
/dtml-with
/dtml-with
as opposed to the following combination
dtml-with sessionmanager
dtml-let SESSION=getSessionData
dtml-var "SESSION['a']"
/dtml-with
/dtml-with
vs
dtml-with sessionmanager
dtml-let SESSION=getSessionData
dtml-call "SESSION.set('a', 'b')"
/dtml-with
/dtml-with
The enforced parity in the former set of DTML snippets between get and set
methods makes the data object a little easier to explain to non-Python
people. And it's easier to explain to Python people that the data object
isn't a mapping than to explain to non-Python people what a mapping is in
the first place and how and why they need to do all the funny quoting and
bracketing. :-)
The __getattr__ interface for retrieval and .set() for insertion might work
better, however, because it doesn't require quoting at all. It still has
the problem that you may want to use an indirect variable name, in which
case you'd need to use something like "_.getattr(sessiondataobject, aname)",
which is just as evil. You also can't do assignments in DTML, so you'd
still need a 'set' method.
A potential rhythm, however, might look like:
dtml-with sessionmanager
dtml-with getSessionData
dtml-call "set('a', 'b')"
/dtml-with
/dtml-with
and
dtml-with sessionmanager
dtml-with getSessionData
dtml-var a
/dtml-with
/dtml-with
I sorta like it the original way now that I've written that down. :-) It's
easier to explain, AFAICS.
___
Zope maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Core Session Tracking kudos namespaces
The advantage of the last form (below), is that you can use
acquisition, and don't need to know whether the variable came from the
session or from elsewhere. If you *really* want it to come from the
session only, you can always add the "only" tag to the dtml-with call.
In conjunction with this, it might be nice to have a special call that
sets the variable, if defined by acquisition, in the session. Something
like dtml-call "sessionmanager.getSessionData.set('a')" would set "a"
to the acquired value for "a", leave it undefined if not defined, and
not change it if it was not acquirable elsewhere (the acquired value
would take precedence over the session value).
Even better would be if I could just say dtml-call
"SESSION.set('a')".
Bob
--- Chris McDonough [EMAIL PROTECTED] wrote:
A potential rhythm, however, might look like:
dtml-with sessionmanager
dtml-with getSessionData
dtml-call "set('a', 'b')"
/dtml-with
/dtml-with
and
dtml-with sessionmanager
dtml-with getSessionData
dtml-var a
/dtml-with
/dtml-with
I sorta like it the original way now that I've written that down.
:-) It's
easier to explain, AFAICS.
__
Do You Yahoo!?
Yahoo! Photos - Share your holiday photos online!
http://photos.yahoo.com/
___
Zope maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Core Session Tracking kudos namespaces
And as I've just figured out by trying to convert some stuff to sessions, a not unconsequential result of allowing session variables to be acquired (if only for read purposes), is that existing code is easier to adapt. I might now call a script without burying form variables or parameters in the URL. If I use implicit acquisition (where the posted form data and URL data is read FIRST), then I can gracefully upgrade these scripts without changing anything. With the current scheme I have to go and search out all occurences of variables like "customer_id" and change them to session syntax. So I guess I'm arguing that the read case and write cases are fundamentally different, that you basically want to support the introduction of session variables into the namespace for read purposes through acquisition, and it's (marginally) OK if read/write don't share the same syntax. Bob Bob Sidebotham wrote: The advantage of the last form (below), is that you can use acquisition, and don't need to know whether the variable came from the session or from elsewhere. If you *really* want it to come from the session only, you can always add the "only" tag to the dtml-with call. __ Do You Yahoo!? Yahoo! Photos - Share your holiday photos online! http://photos.yahoo.com/ ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
