En Mon, 23 Apr 2007 03:35:42 -0300, Martin Drautzburg <[EMAIL PROTECTED]> escribió:
> Gabriel Genellina wrote: > >> En Sun, 22 Apr 2007 12:47:10 -0300, Martin Drautzburg >> <[EMAIL PROTECTED]> escribió: >> >>> I was thinking that it would be nice if a web application could talk >>> to real objects. The client side does not need to know the internals >>> of an object, it acts as a "view" for server-side models. All it has >>> to be able to do is invoke methods on "its" model. So a view could >>> just store "its" object-reference in an instance variable and pass it >>> to the server, where my problem of looking it up comes in. >> >> This is more or less what several web frameworks do. You publish >> objects; URLs are mapped to method objects; URL parameters become >> method parameters. See http://wiki.python.org/moin/WebFrameworks > > Okay will look. I have checked out cherrypy, but it does not seem to > support direct object references, i.e. the server-side objects are > really stateless and all calls to an object method will see the same > state unless you do something about it youself. The description I wrote above aplies exactly to ZOPE: URLs map exactly to object methods and those objects can (and should) maintain state. (Zope uses an OO database, ZODB, to hold those objects). But Zope is a big framework and not easy to grasp, so I would not recomend it for a small site or web application. Using CherryPy you can keep state across requests, if you use some sort of session machinery; at least you could build a mapping SessionID-State (the state being as complex as you want). I think TurboGears has something built in for managing sessions, but I'm not sure. > I have also looked at the wonderful qooxdoo javascript framework and in > the examples they have, the data I receive on a published object method > on my cherrypy server is: Never used qooxdoo... -- Gabriel Genellina -- http://mail.python.org/mailman/listinfo/python-list