Problem actually solved (by digging arount in how-tos). Some remarks: Yes, I save the state of the boxes with their properties. Where else should an object save its state? I mean, "state" IS a property of the object. In terms of object orientation, this seems to me to be a much more logical design than to save session stuff in some non-zope external database or file. O.k., my ZODB might grow, but is it really that much of a problem (I mean, a problem that can not be solved by just packing the DB once in a while)? Any experience with that out there? The problem with concurrent users switching each other's boxes from one state to the other only occurs if they use the same objects. What I use in my implementation is seperate box objects in different user folders. Those objects only contain stuff that is customized. All "heavy lifting" is done by methods in the aqcuisition path, so that there is no real duplication of code even though the complete box structure is duplicated. In a later stage, those objects (currently just empty folders with a view properties ...) will become instances of a class. The cool thing about this is that the portal becomes extremely customizable. You can add boxes only you can see, use different rendering methods, style sheets, whatever can be put into a folderish object. My idea is actually working quite well now. I'll try to make it a ZClass and put it on the web. But first I want to do some testing. As soon as I find the time for it, I'll put my ideas into a how-to. Joachim Wener. Am Mon, 20 Mär 2000 schrieb R. David Murray:
On Thu, 16 Mar 2000, Joachim Werner wrote:
I'm working on a thing I'll probably call "ZBox"; it's a "widget method" that creates HTML-table based boxes on the screen that can be maximized and minimized, like the ones on some of the big web portals. [...] Where should one put the method to update the property status? The tricky thing is that after the update the site from where the request came has to be re-rendered!
Is this really what you want to do? Under this scheme, user 1 views the site, clicks on the maxamize box, and gets the rerendered page. Now user 2 visits the site, and sees the maximized box. He doesn't want that one, so he minimizes the box. Now user 1 clicks to maximize some other box, and suddenly his previously maximized box is minimized.
Or am I missing something about your design?
In any case, changing properties in this way to store state is going to cause your ZODB to grow quickly as each property state change is stored as a new, undoable, transaction.
I know I could switch to cookies or SQL-based stuff. But that wouldn't make the solution flexible for use with Zope objects.
It seems to me you want to use either some sort of Session product to retain the state, or do what I suspect the tree product does and put the state you need to set/save into the URL using argument passing ("?xxx=yyy") or by using forms to submit the change requests and storing the state in 'hidden' fields in the frorm.
--RDM
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )