Controller Newbie Question
dave
I'm just getting started with pylons and I have a question. Here's
the basic setup.
1. My controller index function sets some class variables. (eg.
self.myvar )
2. It then renders a template.
3. The template html loads some javascript in the standard html way
( eg. <script type="text/javascript" src="my javascript.js"></
script> )
4. The page is loaded and all is happy.
5. On a certain action, the javascript get's called and I'd like to
point back to my controller object.. calling a different function.
But it seems that it creates a new instance of the class because the
'self.myvar' no longer exists.
.
Any help greatly appreciated.
Here's a bit different way of explaining it
class WbController(BaseController):
def index(self):
# get some info from the urlr
self.myvar = "some info here"
# pass that info to the template.
return render('/foo.mako')
def foo(self):
# foo get's called by the javascript that is loaded in the
template..
# but self.myvar doesn't exist !!!??
------------------ javascript snip---------
var url = "wb/foo";
xmlhttpPut.onreadystatechange=empty;
xmlhttpPut.open("GET",url,true);
xmlhttpPut.send(null);
many thanks,
david
Christoph Haas
Your class variables are not saved between HTTP requests. If you want
data to persist you either need to save it in into a database (hint:
model) or into the session (cookie based session).
Cheers
Christoph
--
em...@christoph-haas.de www.workaround.org JID: chr...@jabber.workaround.org
gpg key: 79CC6586 fingerprint: 9B26F48E6F2B0A3F7E33E6B7095E77C579CC6586
Raoul Snyman
> Your class variables are not saved between HTTP requests. If you want
> data to persist you either need to save it in into a database (hint:
> model) or into the session (cookie based session).
Just to further explain what Christoph has said, since I had the same
misconception as Dave when I started writing web apps...
In the traditional software model, once an object is created within
the application, it remains there until either it is destroyed or the
application is closed. In Web Apps, this is not the case. In essence,
each and every page that you go to is a single execution of your
application... from startup to shutdown. This means that while the
page is loading your object is valid, but as soon as the page has
finished loading, your object has been destroyed. So any variables you
set in your controller are not available on the next page or function
execution.
As Christoph also said, the way to make data persist between different
pages is either via database storage, or via the "session" list object
in your controller. In Dave's case, he most probably wants to use the
session list object.
Here's an example:
if 'message' not in session:
session['message'] = 'This is a message'
session.save()
--
Raoul Snyman
B.Tech Information Technology (Software Engineering)
E-Mail: raoul....@gmail.com
Web: http://www.saturnlaboratories.co.za/
Blog: http://blog.saturnlaboratories.co.za/
Mobile: 082 550 3754
Registered Linux User #333298 (http://counter.li.org)
Mike Orr
>
> On Tue, Apr 8, 2008 at 6:39 PM, Christoph Haas <em...@christoph-haas.de> wrote:
> > Your class variables are not saved between HTTP requests. If you want
> > data to persist you either need to save it in into a database (hint:
> > model) or into the session (cookie based session).
>
> Just to further explain what Christoph has said, since I had the same
> misconception as Dave when I started writing web apps...
>
> In the traditional software model, once an object is created within
> the application, it remains there until either it is destroyed or the
> application is closed. In Web Apps, this is not the case. In essence,
> each and every page that you go to is a single execution of your
> application... from startup to shutdown. This means that while the
> page is loading your object is valid, but as soon as the page has
> finished loading, your object has been destroyed. So any variables you
> set in your controller are not available on the next page or function
> execution.
Well, yes, but not precisely. A web app has several kinds of state
(scopes). "Request" state lasts for the duration of the request.
Pylons instantiates a controller for every request; another framework
might use the same instance for every request. So in Pylons the
'request' object and controller instance are request scope.
Session scope ties together several requests by the same user running
the same browser. In Pylons the "session" object has session scope,
so anything you put into it is visible in later requests within the
session. Normally the session ends when the user quits the browser,
but you can make it longer or shorter by setting the expiration time
of the session cookie, or by deleting the session data on disk (in
myapp/data/sessions). So session scope sounds like what you want.
Persistent scope lasts forever, or at least until you delete it or the
hard disk keels over and dies. In Pylons the model -- tied to a SQL
database or such -- is persistent. But here you must think about
whether the data should be visible to everybody, or to just the user
who created it. To keep it private to the user, you'll have to put a
username field in the record, and set up authentication to find out
who the user is. (You could also keep session data in the database,
though there's no reason to. But if you wanted to, you'd key it by
session ID, which is "session.id" in Pylons.)
There are also several global scopes, which are shared by all requests
and users. Pylons' "g" variable is one. So is any module you import,
or any controller class, or any Python global. Some of these are
shared between threads, while others may be thread local. Ask on the
list if you're not sure if you're modifying something in a thread-safe
manner. Global data disappears when the Pylons application quits.
Your original message and replies said "class variables". Those would
be attributes attached to the controller class, not "self" variables
attached to the instance. ('MyController.foo = "bar"' as opposed to
'self.foo = "bar"'.) Class attributes are global scope; instance
attributes are request scope.
--
Mike Orr <slugg...@gmail.com>