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 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
> 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!
Zope maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -