[Zope] Fwd: How do I set properties from DTML? (Repost)

[Joachim Werner]

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 )