--> Saturday, August 30, 2003, 5:48:34 AM, [EMAIL PROTECTED] wrote:
> Let me see if I can flesh out the question?
> Application level was across all clients, in webware's terminology I would call
> this Context-level (or if your contexts are shared/one-site, this could be
> Application-level). They did not survive appserver restarts.
Is req.transaction().application() the entire AppServer? I don't even deal
with contexts. I used MakeAppDir and don't have any servlets in my web
directory, I inherit from them in PSP pages, I don't use the /WK/ url stuff.
All that is somehow ill in my opinion.
So, I am looking for what I suppose is context level, but I wouldn't know.
I can't even remember what contexts are supposed to be anymore. I run
AppServer from a website directory, which itself has a directory I created
called 'site' for PSP pages (which is the document root for the site in
Apache) and a directory for Servlets and other modules to be imported (lib,
which I didn't create).
Maybe I remember now, is that 'site' the context? Doesn't matter to me..
> If this is what you're looking for, your example code from another mail
> (attaching a var to transaction().application()) works for me, although to
> avoid editing/resaving I did it in two separate psp files: one to set, one to
> read. Are you using OneShot.cgi, or do you have AutoReload set for the
> Application.config? My guess is you are seeing the effects of variables that
> don't survive appserver restarts. Of course, restarts are a lot more
> common/accepted in Webware because of the seamless session persistence and
> python module messiness.
Oops, it was autoreloading, so I disabled that and my guess code works.
However, disabling the autoreloading will probably plague me now.
Since Webware does accept common restarts, and at the mention of "seamless
session persistence", perhaps we should be allowed an official mechanism for
application/context/server scope variables with autoreload persistence?
> If you don't really need them to persist, then just make sure they are
> initialized somewhere in your code (awake, or perhaps contextInitialize).
> However, style-wise there are better ways to do this for non-persistent data
> in python, such as module-level singletons. Notice that in this case,
> application-level is the same as python-interpreter-level. This would be
> appropriate for things that just need to be accessible to all of the
> application (often used for database connection sharing in Webware, for
> example.)
Right, I was recommended this Huy Do from this list, so I wrote a globals.py
and tried to use it from a PSP page. It was fairly troublesome, and I do
think I had it doing something once, although I did keep running into
'accessed before initialized' errors in my various testing. Basically, it
was acting strangely, so I gave up, just a few minutes a go.
I would prefer something *like* an official dictionary in
req.transaction().application() (or wherever), with autoreload persistence.
> If you do need the data to persist, then I believe you'll have to look at
> either classic persistence such as database or file storage, or at hooking
> something into webware much like the Session stuff to store your info to
> disk/database at appserver shutdown, and then in contextInitialize or similar
> to restore it. (See transaction().application().addShutDownHandler() in
> Webkit/Application.py)
Nope, this are very RAM-loving data. It will persist only if the developer
decides to make it do so and then by whatever means he wishes to conjure.
> Whew, probably a little long-winded, hope this helps.
So, there is no current mechanism for doing this? Is adding attributes to
req.transaction().application() frowned upon?
What does everyone think of adding an official location for larger scoped
variables. A dictionary in req.transaction().application() I suppose..
-Kai
P.S. This all assumes you are willing to accept a larger in-memory
scope is indeed very useful in advanced web applications.
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Webware-discuss mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/webware-discuss
