On 5/21/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
I think out of sheer laziness and excitement to get up and running I
defined a few lists in my controller's global namespace to which I
append data used by other controllers during other calls. The lists
seem to persist between calls which is great, however I haven't seen
this used in any of the tutorials so should I be storing this stuff in
the db ? It's app data that doesn't needs to stick around for very long
and is constantly being overwritten. What is the best practice for
sharing lists between controller calls and out of curiosity where is
this state coming from ?
The "constantly being overwritten" part scares me. It's fine to store
data globally if it's the same for all users. I have a feeling that's
not the case here, and you're going to run into problems where users
would see each other's data.
If the data only needs to live for one request (not what I gather from
your post), then you can just attach it to the cherrypy.request
object.
If it needs to last between requests, you can store it:
1) in cookies or other client-side mechanisms (which is great for
scaling, if you're planning to have millions of users)
2) in the database
3) in sessions
(the above is my order of preference, YMMV. also depends on needs of
application).
Kevin
X-Google-Language: ENGLISH,ASCII-7-bit
Received: by 10.54.68.15 with SMTP id q15mr173243wra;
Sun, 21 May 2006 11:00:02 -0700 (PDT)
Return-Path: <[EMAIL PROTECTED]>
Received: from nz-out-0102.google.com ([64.233.162.202])
by mx.googlegroups.com with ESMTP id v23si725314cwb.2006.05.21.11.00.01;
Sun, 21 May 2006 11:00:02 -0700 (PDT)
Received-SPF: pass (googlegroups.com: domain of [EMAIL PROTECTED] designates
64.233.162.202 as permitted sender)
DomainKey-Status: good (test mode)
Received: by nz-out-0102.google.com with SMTP id n1so1531834nzf
for <[email protected]>; Sun, 21 May 2006 11:00:01 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
s¾ta; d=gmail.com;
h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
b=tnh8hSP5rJ5pLm+ajwPnq1maVWHteEJURqrCyM5X+COwgFlpSU0Nmm9zr1XeQ3S5pZYhHXMXslfc6LnF1FHsCp77fMScjyz3fOeXBYiExeAYIPnhj6Kq3TvL8oePxrOw6aA3uy64S2Nvh8522a1AYfrJJwpy+O9wKuNHT4nwFGsReceived:
by 10.64.152.6 with SMTP id z6mr219919qbd;
Sun, 21 May 2006 11:00:01 -0700 (PDT)
Received: by 10.65.159.9 with HTTP; Sun, 21 May 2006 11:00:01 -0700 (PDT)
Message-ID: <[EMAIL PROTECTED]>
Date: Sun, 21 May 2006 14:00:01 -0400
From: "Kevin Dangoor" <[EMAIL PROTECTED]>
To: [email protected]
Subject: Re: [TurboGears] Question about state between controller calls
In-Reply-To: <[EMAIL PROTECTED]>
Mime-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable
References: <[EMAIL PROTECTED]>
On 5/21/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
I think out of sheer laziness and excitement to get up and running I
defined a few lists in my controller's global namespace to which I
append data used by other controllers during other calls. The lists
seem to persist between calls which is great, however I haven't seen
this used in any of the tutorials so should I be storing this stuff in
the db ? It's app data that doesn't needs to stick around for very long
and is constantly being overwritten. What is the best practice for
sharing lists between controller calls and out of curiosity where is
this state coming from ?
The "constantly being overwritten" part scares me. It's fine to store
data globally if it's the same for all users. I have a feeling that's
not the case here, and you're going to run into problems where users
would see each other's data.
If the data only needs to live for one request (not what I gather from
your post), then you can just attach it to the cherrypy.request
object.
If it needs to last between requests, you can store it:
1) in cookies or other client-side mechanisms (which is great for
scaling, if you're planning to have millions of users)
2) in the database
3) in sessions
(the above is my order of preference, YMMV. also depends on needs of
application).
Kevin
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"TurboGears" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/turbogears
-~----------~----~----~----~------~----~------~--~---
