Re: [Zope] Core Session

2001-01-29 Thread Chris Withers

josh on wrote:
 
 Is core session a part 2.3?

I thought it was, but it doesn't look like it made it into 2.3.0 :-(

Any ideas when it will land?

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

2001-01-29 Thread Chris Withers

Chris McDonough wrote:
 
  Any ideas when it will land?
 
 Nope.  It's pretty stable now, but any release that shows up in the core
 depends on a new BTree implementation, which has been slow in the making.

rats... although I'd love to see a snappy new BTree implementation... got lots
of projects that use the current one :-)

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

2001-01-29 Thread Chris McDonough

 Any ideas when it will land?


Nope.  It's pretty stable now, but any release that shows up in the core
depends on a new BTree implementation, which has been slow in the making.


___
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

2001-01-28 Thread Chris McDonough

Hi Josh,

No, the core session tracking product does not ship with
2.3.  But it does work with it.  You can get it from
http://www.zope.org/Members/mcdonc/Products/CoreSessionTracking



On Sun, 28 Jan 2001 17:19:32 -0800
 "josh on" [EMAIL PROTECTED] wrote:
 Is core session a part 2.3?  
 Can someone point me to the documentation on it?
 
 Thanks,
 
 josh on
 
 
 ___
 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

2001-01-07 Thread Chris McDonough

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

2001-01-07 Thread Tres Seaver

"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

2001-01-04 Thread Chris Withers

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

2001-01-04 Thread Phil Harris

- 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

2001-01-04 Thread Dieter Maurer

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

2001-01-04 Thread Bob Sidebotham

--- 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

2001-01-04 Thread Bob Sidebotham

--- 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 DTML

2001-01-03 Thread Chris Withers

Chris McDonough wrote:
 
   dtml-with sessionmanager
 dtml-with getSessionData
   dtml-var "get('a')"
 /dtml-with
   /dtml-with

I would have thought this stuff would be better in a python script:

sessionmanager.getSessionData.get('a')

...since it is definitely 'logic'

Would it be posible to make that even nicer and have whatever
getSessionData is implement __getattr__ so you could do:

sessionmanager.SessionData.a

...or something similar?

just my 2p,

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 DTML

2001-01-03 Thread Chris McDonough

 Chris McDonough wrote:
 
dtml-with sessionmanager
  dtml-with getSessionData
dtml-var "get('a')"
  /dtml-with
/dtml-with

 I would have thought this stuff would be better in a python script:

 sessionmanager.getSessionData.get('a')

Yeah, I'm jus using DTML because it's the more pathological case and needs
to look pretty in DTML first.  :-)


 ...since it is definitely 'logic'

 Would it be posible to make that even nicer and have whatever
 getSessionData is implement __getattr__ so you could do:

 sessionmanager.SessionData.a

 ...or something similar?

Yes.  That's what Bob S. suggested.  What are the benefits of this?



___
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 DTML

2001-01-03 Thread Chris Withers

Chris McDonough wrote:

  sessionmanager.SessionData.a
 
  ...or something similar?
 
 Yes.  That's what Bob S. suggested.  What are the benefits of this?

More graceful code that's more 'pythonesque' in Python Scripts:

if sessionmanager.SessionData.a['mykey'] == 1:
...as opposed to...
if sessionmanager.SessionData.get('a')['mykey'] == 1:

sessionmanager.SessionData.b = 1
...as opposed to...
if sessionmanager.SessionData.set('b',1)

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 DTML

2001-01-03 Thread Chris McDonough

 Chris McDonough wrote:

   sessionmanager.SessionData.a
  
   ...or something similar?
 
  Yes.  That's what Bob S. suggested.  What are the benefits of this?

 More graceful code that's more 'pythonesque' in Python Scripts:

 if sessionmanager.SessionData.a['mykey'] == 1:
 ...as opposed to...
 if sessionmanager.SessionData.get('a')['mykey'] == 1:

The current way is:

if sessiondatamanager.getSessionData()['mykey'] == 1:
.. do something...

I suppose you'd rather see:

if sessiondatamanager.getSessionData().mykey == 1:
.. do something...

Is this really worth it?

 sessionmanager.SessionData.b = 1
 ...as opposed to...
 if sessionmanager.SessionData.set('b',1)

And this is currently:

sessiondatamanager.getSessionData().set('b',1)

You can't do assignment in DTML, and session-tracking needs to be usable
from DTML, so the "ob.attr = val" idiom is out from the get-go.  Another
assumption I'm making is that  "there should only be one way to do it".  I'd
rather not have both __setattr__ and .set work for session data objects,
because it's confusing and doesn't buy anything at all other than a couple
keystrokes.



___
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 DTML

2001-01-03 Thread Chris Withers

Chris McDonough wrote:
 
 You can't do assignment in DTML, and session-tracking needs to be usable
 from DTML, so the "ob.attr = val" idiom is out from the get-go.  Another
 assumption I'm making is that  "there should only be one way to do it".  I'd
 rather not have both __setattr__ and .set work for session data objects,
 because it's confusing and doesn't buy anything at all other than a couple
 keystrokes.

Fair enough :-)

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 DTML

2001-01-03 Thread Chris McDonough

 Chris McDonough wrote:

   sessionmanager.SessionData.a
  
   ...or something similar?
 
  Yes.  That's what Bob S. suggested.  What are the benefits of this?

 More graceful code that's more 'pythonesque' in Python Scripts:

 if sessionmanager.SessionData.a['mykey'] == 1:
 ...as opposed to...
 if sessionmanager.SessionData.get('a')['mykey'] == 1:

The current way is:

if sessiondatamanager.getSessionData()['mykey'] == 1:
.. do something...

I suppose you'd rather see:

if sessiondatamanager.getSessionData().mykey == 1:
.. do something...

Is this really worth it?

 sessionmanager.SessionData.b = 1
 ...as opposed to...
 if sessionmanager.SessionData.set('b',1)

And this is currently:

sessiondatamanager.getSessionData().set('b',1)

You can't do assignment in DTML, and session-tracking needs to be usable
from DTML, so the "ob.attr = val" idiom is out from the get-go.  Another
assumption I'm making is that  "there should only be one way to do it".  I'd
rather not have both __setattr__ and .set work for session data objects,
because it's confusing and doesn't buy anything at all other than a couple
keystrokes.



___
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

2001-01-03 Thread Dieter Maurer

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

2001-01-03 Thread Chris McDonough

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 )




Re: [Zope] Core Session Tracking kudos namespaces

2001-01-02 Thread Chris McDonough

 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

2001-01-02 Thread Bob Sidebotham

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

2001-01-02 Thread Bob Sidebotham

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 )




Re: [Zope] Core Session Tracking kudos namespaces

2001-01-02 Thread Chris McDonough

Bob,

Responding to both of your messages in this one...

Actually, in the current implementation, session data objects are not
acquirers, so the syntax you're advocating won't do what you think it might.
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.  This could be changed.  We could make
data objects acquirers.  I can see the rationale for something like this,
where you want to "fall through" to a default acquired value.   Session data
object interaction with acquisition was something I didn't think about at
all.  I'm glad you've brought it up.


Note that it's also possible to do something like:

dtml-let bar=amethodcall
  dtml-with sessiondatamanager
dtml-with getSessionData
  dtml-var "get('foo', bar)"
/dtml-with
  /dtml-with
/dtml-let

Which will return the rendering of bar (which is itself the result of
'amethodcall') if a value for 'foo' cannot be found.  This is way more
verbose than just acquiring 'amethodcall', but it's very understandable.

Currently, I'm leaning towards leaving it explicit both in syntax (explicit
set and get methods) and semantics (no acquisition), because we've gotten in
a lot of trouble in the past when attempting to do likeminded magical
things -- like making all common Zope objects acquisition-implicit.  And
although acquisition isn't that magical, it can sure blow up on you when you
don't know what you're doing.  Murphy's law says that this will happen to
every newbie, and I'll be left holding the bag.  ;-)

As for some of your other points:  The current interface is very verbose.
I'm just not sure that's such a bad thing.  :-)  You can do something like:

dtml-call "sessiondatamgr.getSessionData().set('aname', 'avalue')"

... if you don't want to do all the dtml-withs and -lets.

God help me though, I am thinking of aliasing the __call__ method of a
session data manager to getSessionData, so that this would work:

dtml-with sessiondatamgr
   dtml-call "set('aname', 'avalue')"
/dtml-with

or this:

dtml-call "sessiondatamgr().set('aname', 'avalue')"

This might be explainable.  It reminds me however of a similar feature of
the catalog that is very hard to explain (the aliasing of searchResults to
__call__), and it makes me want to not do it.  If I do do it, getSessionData
will disappear from the interface, and there will only be one way to do it
(via a session data manager's __call__).

I'm not sure I understand your desire to do:

dtml-call "sessiondatamanager.set('a')"

I particularly don't understand what would end up getting rendered if (as
per your syntax) you subsequently did:

dtml-var "sessiondatamanager.a"

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, because this implementation was done sort of clean-room
style and thus may lack real-world practicality.  I haven't used it as a
component in any development personally.  Having some real examples of
conversion work or initial implementation work to chew on might help me
markedly improve the implementation.  Some of my arguments may be an
overreaction to past problems, and you may need to straighten me out with
some examples of how making session data objects acquirers and making the
interface less verbose could help more than it could hurt in a real-world
app.

Thanks much for all the input!

- C


- Original Message -
From: "Bob Sidebotham" [EMAIL PROTECTED]
To: "Chris McDonough" [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Tuesday, January 02, 2001 11:55 PM
Subject: 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 sessi