>
> manage="REQUEST.get('manage_content') or
> data.get('manage_content')">
>
>
>
>
>
>
>
>
>
This will work for the "manage_content", but I want to make the whole
request persistent. E.g., box states, search filters, and sequence-start
variables for batc
Hi Joachim,
I'm confused as to the utility of this bit of code.
You loop over the items in the REQUEST.form dict, putting them all into
session storage except for 'file'.
Then you loop over all the items in the session data object, putting
them into the REQUEST.other dict.
Why the first step?
> > I know, but that's why the errors are called "random": They are not easy
to
> > replicate ...
>
> I understand.
I don't know if this helps a bit: It's the code used in KONTENTOR for
putting the session into the REQUEST namespace. I think it is not the most
elegant way of doing this, but it se
out a change in a complex
object, e.g., dict?
Bye,
--
Bjorn
-Original Message-
From: Matt Hamilton [mailto:[EMAIL PROTECTED]]
Posted At: Saturday, May 26, 2001 00:37
Posted To: Zope Developer
Conversation: Randomness (RE: [Zope-dev] CoreSessionTracking 0.8)
Subject: RE: Randomness (RE: [Z
On Fri, 25 May 2001, Bjorn Stabell wrote:
> session = context.session_mgr.getSessionData()
>
> cart = session.get('shopping_cart', {})
>
> sku = int(sku)
>
> if not cart.has_key(sku):
> cart[sku] = 0
>
> if int(qty)>0:
>cart[sku] = cart[sku] + int(qty)
Could this be the same problem
By the way, Chris, you can see the bug in action at our site by going
to:
http://www.beijingsammies.com:7380/sammies/
The website has not been launched yet, so be careful guys. Also, don't
try ordering, unless you're in Chaoyang district, Beijing, China. :)
The site may be slow since it
Chris McDonough:
[...]
> weeping (although grateful for the exchange),
I'm sorry Chris. We didn't give you a very good debugging chase. I
know how frustrating bug reports like "Help! It doesn't work" is, but I
guess it's very hard to troubleshoot bugs in frameworks since there's so
much customi
Chris McDonough wrote:
>
> Note that I just changed CST to unwrap aq-wrapped objects just in case,
I always wondered why Squishdot did this, now I know :-)
cheers,
Chris
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listi
Chris McDonough wrote:
>
> To further try to track this problem down, I've developed a "burger,
> fries, coke" application in honor of this thread. So far, I've eaten
> 84 burgers, 31 cokes, and 42 fries. I can't seem to break this thing,
> and I'm not hungry anymore. :-(
Sorry, but I had to
Chris McDonough wrote:
> If the answer is 2, everything's not so fine. I'll likely need to
> change the CST code to unwrap acquisition-wrapped objects before storing
> them, just to head potential problems off at the pass. I just did a
> preliminary test, and it appears that it *is* storing
> ac
Matt Hamilton wrote:
> Looking into it further I don't think it is a CST fault :) I think I have
> fixed the problem. It was me not setting _p_changed on an object with a
> dict after adding items to the dict. Hence the session wasn't being lost,
> just the conents of the cart itself were not v
On Fri, 25 May 2001, Chris McDonough wrote:
> Bummer. How long is the session data container timeout set for? Are
> you sure you're just not exceeding the timeout?
The session timeout is 120 minutes. I am using an external
SessionDataComainter stored in the normal undo-able ZODB (I'm not
expe
Matt Hamilton wrote:
> Just to add myself to the list, I too am having problems with
> CoreSessionTracking :( I am trying to find a test case for the problem,
> but I really can't replicate it. It first I thought it was a cookie
> issue, but I am now noting down the session id generated and it s
To further try to track this problem down, I've developed a "burger,
fries, coke" application in honor of this thread. So far, I've eaten
84 burgers, 31 cokes, and 42 fries. I can't seem to break this thing,
and I'm not hungry anymore. :-(
I just wanted to throw this out there. I'm certain t
Chris McDonough wrote:
> I just wrote a test case that emulates many visitors firing off sessions
> and making changes to shared data objects simultaneously. It even
> emulates aborted connections. Unfortunately, I see nothing out of the
> ordinary. :-( This is very frustrating.
Maybe the pro
Joachim Werner wrote:
>
> > However, a much more helpful report would be
> > one which provides a repeatable test case which invariably reproduces
> > the problem instead of one which states the symptoms and effects of the
> > problem.
>
> I know, but that's why the errors are called "random": T
> However, a much more helpful report would be
> one which provides a repeatable test case which invariably reproduces
> the problem instead of one which states the symptoms and effects of the
> problem.
I know, but that's why the errors are called "random": They are not easy to
replicate ...
_
On Thu, 24 May 2001, Chris McDonough wrote:
> These "it appears CST is unstable" reports are helpful to an extent
> (from Bjorn, Joachim, and Howard), as it lets me know that something
> needs to be done to CST. However, a much more helpful report would be
> one which provides a repeatable test
These "it appears CST is unstable" reports are helpful to an extent
(from Bjorn, Joachim, and Howard), as it lets me know that something
needs to be done to CST. However, a much more helpful report would be
one which provides a repeatable test case which invariably reproduces
the problem instead
What we experience with CoreSessionTracking:
We have a manage mode in the Kontentor CMS hacky thing (no, it is NOT a
product yet ;-)). It works well for some time (i.e. if I click on it, the
system switches to manage mode and stays in manage mode until I click
again), but from time to time it is
It's obvious. This is just Zope's way of telling you not live on hamburgers
and coke.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
Bjorn Stabell
Sent: Thursday, May 24, 2001 12:33 AM
To: Chris McDonough; Howard Zhang
Cc: [EMAIL PROTECTED]
Subject: Rand
21 matches
Mail list logo