Fwd: How do I set properties from DTML? (Repost)
I'm reposting due to mail problems of my provider ... 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. My first simple try with just using Folders, two methods, and properties, worked quite well. I created a method that looks up whether the box is minimized or maximized and renders it respectively. The box itself is a (currently empty) folder that has a property "max" that can be "show" or "hide" (could also be boolean, but I'm thinking of other states like "just show headlines"). The content would then be rendered by other methods that are called in a "content" method by the "box" method. Using those boxes on the site curently looks like this (for a folder "news_box" containing the content): <dtml-with news_box> <dtml-var box> </dtml-with> The problem I could not solve with my very limited Zope knowledge is how to "switch" the boxes from minimized to maximized et vice versa. In other words, I'd need a DTML expression that I can put into a method that is called by a hyperlink on the "minimize/maximize" button to switch the property state and then returns the site again. The two problems are: How can I set a property in DTML (REQUEST.set won't work as far as I can see it)? Namespaces could be quite tricky with that. 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! I know I could switch to cookies or SQL-based stuff. But that wouldn't make the solution flexible for use with Zope objects. Am I on the right path? If the whole thing doesn't work out that way I could try using my own tree tag version that renders a box instead of the "+"/"-" stuff). Doesn't sound that easy. Thanks a lot for suggestions! Joachim Werner Iuveno - Smart Communication ------------------------------------------------------- -------------------------------------------------------
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
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 )
On Mon, 20 Mar 2000, Joachim Werner wrote:
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.
Yes, what I didn't know about your design was that the objects in question were specific to the user. In that case, and if it is not expected that the user will want to change his settings with every session but instead this is a customization feature, then what you have described sounds like an ideal application of Zope and its object machinery.
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?
I think it all depends on how frequent the updates are and how many users you have. If your site gets to be high enough traffic and users make frequent enough changes for it to be a problem, you could always switch to an undo-less backing store for the ZODB and therefore not have to change your implementation to continue to scale. Others with direct experience with portal-like sites may have more useful input. Are you, by the way, aware of the Portal Toolkit project? I haven't investigated it yet, but if you aren't following it it sounds like something you'd be interested in. I'm sure they are thinking about scalability issues there. --RDM
participants (2)
-
Joachim Werner -
R. David Murray