Well the problem that I am having with all of this is the notion of the svr *reconstituting* the state upon each request. Sure, the svr must always have to identify the client and shuttle the request to the desired functionality, but I didn't know the operating paradigm here was that the "session data" was kept in a file, a key to that file was created, and then the key was returned to the client, which must thereafter send back this cookie in order to identify itself. This action is fine for authentication but it is insufficient for interacting with a complex model that is constructed from (many) database tables and cached and organised in instantiated code objects. I do not think it is economical to reconstruct the code objects upon each and every request - thus my shock.
I stumbled into this situation because after coding up my client to render the create/update/delete record model and view and the gridtable for multiple-record selects, I realized that all my calls back to the svr were basically DAL renderings of CRUD into data base tables. I thought that it would be better to move the business logic back into the svr. (E.g. some important table constraints are more easily encoded into the python code than into the db, as I am starting with SQLite, which does not support much in the way of table constraints, but will want to move onto postgres later). I guess I just have to maintain that all access to the database tables goes thru the business logic, in order to maintain its integrity. I can do this in the client if no other client of any kind can, at some later time, gain access to the tables. This may sound odd but the last company I worked for had this set up (in a major, internationally well known, well used app). They used Crystal Reports to render their reports via direct access to the tables and this caused no end of problems (eg. some data was rendered on the fly by the business logic when the tables are accessed from the app. Of course, this data does not exist for the reports, because it does not exist in the database tables. Oh the fun we had... ) === Rb "web programming is haard." On Aug 12, 12:23 am, Yarko Tymciurak <yark...@gmail.com> wrote: > Ahem.... > > "Knock, knock!" --- says the browser... > "Whose there?" --- says the server... > > If the request (browser) identifies itself with information given it by the > server as a continuation from a recent identification, then the normally > stateless nature of the web get's state, established by the client > identifying itself to the server.... typically this is done by cookies. > > Client not saving session id? Then client cannot establish it's identity > --- eg. server has no session to "restore" --- this is a fresh (e.g. > stateless) session. > > Seehttp://en.wikipedia.org/wiki/Session_management for a bit of a > conceptual overview. > > On Wed, Aug 12, 2009 at 1:14 AM, rb <rbspg...@gmail.com> wrote: > > > Thx kindly, Massimo. I'll check the links out... but... > > > >Once more, the issue is not with web2py. The issue is with your > > client. It does not support cookies, hence it does not support > > sessions. > > > Errr... no, that is not the issue that I'm pointing at. If "sessions > > remain and do not expire" means that in between accesses the session > > global variable is pickled to the disk and then later reconstituted > > from the disk or else pickled into cookies and sent to the client, > > then I have a problem with this definition. I don't think my data is > > necessarily pickle-able. > > > I guess I misread/misunderstood paragraphs like: > > > The option masterapp=None, by default, tells web2py to try to > > retrieve an > > existing session for the application with name in request.application, > > in the > > running application. > > > to imply that there remained a *running process* that kept the session > > variable (and hence my data) instantiated in between calls. I'm new to > > this web app thing. > > > So, thx for the clarification. I'll either try to hack the code you > > referenced or else I'll just end up using the web2py server as a data > > server and keep the business logic in the thick client. > > > --- > > Rb > > > On Aug 11, 10:39 pm, mdipierro <mdipie...@cs.depaul.edu> wrote: > > > Correction. You must use this client: > >http://code.activestate.com/recipes/501148/ > > > not this client: > >http://fotinakis.com/blog/blog/2008/cookies-xmlrpc-and-ssl/ > > > > Massimo > > > > On Aug 12, 12:19 am, mdipierro <mdipie...@cs.depaul.edu> wrote: > > > > > Once more, the issue is not with web2py. The issue is with your > > > > client. It does not support cookies, hence it does not support > > > > sessions. > > > > > If you use this client they should work: > > > > >http://fotinakis.com/blog/blog/2008/cookies-xmlrpc-and-ssl/ > > > > > Massimo > > > > > On Aug 11, 7:31 pm, rb <rbspg...@gmail.com> wrote: > > > > > > Well I need more than just cookies. I can't serialize the app > > > > > inbetween each call. I need a working process, which has active data > > > > > structures (database tables, dictionaires, etc). > > > > > > Is there anyway for an app to talk out through web2py to a client? > > > > > > I had (incorrectly) understood that sessions stick around and remain. > > > > > Even if a session object is cookized in between calls doesn't the > > docs > > > > > say that the session stuff remains? The manual says: > > > > > > === > > > > > 4.8 session > > > > > ------------------ > > > > > is another instance of the Storage class. Whatever is > > > > > stored into session for example: > > > > > > session.myvariable="hello" > > > > > > can be retrieved at a later time: > > > > > > a=session.myvariable > > > > > > as long as the code is executed within the same session by the same > > > > > user > > > > > (provided the user has not deleted session cookies and the session > > > > > did not > > > > > expire). Because session is a Storage object, trying to access an > > > > > attribute/key > > > > > that has not been set does not raise an exception, it returns None > > > > > instead. > > > > > === > > > > > > Thus I can store myvariable into session and retrieve it at a later > > > > > time. What the manual _should_ say, if I understand you now, is that > > > > > the global variable "session" is pickled between each call into a > > > > > cookie and unserialized with each subsequent call. If your protocol, > > > > > eg xmlrpc does not use cookies then you can forget about sessions > > > > > being used to store info to be retrieved at a later time. > > > > > > Argh! This is upsetting. I was thinking that session (and some > > > > > pythonic process) remained running in between calls. Argh. > > > > > > Thx for the link, I'll check it out. (fingers crossed) > > > > > > === > > > > > > On Aug 11, 4:22 pm, mdipierro <mdipie...@cs.depaul.edu> wrote: > > > > > > > This is not a problem with the server but with the client. > > > > > > You may try the cookie aware xmlrpc client proposed here: > > > > > > >http://code.activestate.com/recipes/501148/ > > > > > > > Or you need to pass an extra key to the function calls and is that > > to > > > > > > retrieve a session. > > > > > > > Massimo > > > > > > > On Aug 11, 6:09 pm, rb <rbspg...@gmail.com> wrote: > > > > > > > > Further, I added a : > > > > > > > > session.hello = "hello, world" > > > > > > > > in order to see if it just didn't want to hold onto MY data. No > > dice. > > > > > > > session.hello is gone on the next call as well. > > > > > > > > --- > > > > > > > > On Aug 11, 3:02 pm, rb <rbspg...@gmail.com> wrote: > > > > > > > > > In my think-client xmlrpc protocol to web2py svr code I am > > trying to > > > > > > > > maintain data in the session global variable but it doesn't > > seem to > > > > > > > > hold it. For example I first start by creating a document-form > > (tree > > > > > > > > of datatables), cached in a data structure, as an attribute of > > > > > > > > session. Here's the code: > > > > > > > > > from gluon.tools import Service > > > > > > > > > service = Service(globals()) > > > > > > > > > def call(): > > > > > > > > return service() > > > > > > > > > @service.xmlrpc > > > > > > > > def xrBeginDocFrm( frmName): > > > > > > > > ''' create table records and push xrInitRecord down to all > > tables. > > > > > > > > ''' > > > > > > > > if session.frmz == None: > > > > > > > > session.frmz = {} > > > > > > > > if not session.frmz.has_key("frmName"): > > > > > > > > session.frmz[frmName] = rna.DocFrm(db, frmName) > > > > > > > > > Then later I call the svr to get the table column definitions: > > > > > > > > > @service.xmlrpc > > > > > > > > def xrGetColDefs(frmName, tblInstName): > > > > > > > > tblInst = session.frmz[frmName].GetTblInst(tblInstName) > > > > > > > > return tblInst.GetColDefs() > > > > > > > > > but I find that session does not have a frmz attribute. I can > > walk the > > > > > > > > debuger through the svr code so I can see that the functions > > are > > > > > > > > getting called, but when I inspect session it contains nothing. > > > > > > > > > I thought sessions stick around forever? I thought that session > > was > > > > > > > > the place to keep my own attributes that will live on (between > > xmlrpc > > > > > > > > calls). > > > > > > > > > Heeeeelp! --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to web2py@googlegroups.com To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~----------~----~----~----~------~----~------~--~---
