[ZClass] manage_beforeDelete
Hello, I have a ZClass which saves some data to disk. Now, when I delete an instance of this ZClass I want also unlink the data on disk. I thought this could be done by overriding the manage_beforeDelete method, but this is impossible as my own manage_beforeDelete gets overridden by SimpleItem.manage_beforeDelete which is added as last item in the inheritance path... Any ideas ?? Sascha -- .-> Sascha Matzke - sascha@bespin.de - http://www.bespin.de -. | Read the sourcecode, Luke... | | Obi Wan Kenobi | `-- On this earth for 23 years, 357 days <----------------'
I've been reading the Spetra/Zope comparisons with interest. My company is investigation Zope and Vignette. Do any of you have experience with them that you'd like to share? How easy is it to work with, how flexible is it, etc? I get to go to a Vignette presentation tomorrow. Do any of you have any advice about what to look for and/or ask? Thanks, -- --Michael
First, I'd like to that Chris and Anthony who gave me some pointers for things to look out for at the meeting with Vignette. I hope that it is not inappropriate to post my reactions to this list. I think many of us are interested in comparisons of Zope to other products. What is clear to me is that Vignette has much better marketing. As a developer, I really liked the fairly technical discussion I had a Digital creations. We talked a lot about _how_ Zope does what it does, but not much about _what_ it can do. Vignette had a pretty good canned presentation of the many things is can do, but very little discussion of how it works. Part of the problem may be that Zope can do everything, so where do you start when you present it :), but mostly it is that Vignette has a marketing mindset and Digital Creations has an engineering mindset. (Which I like, I should add.) Below I've put an edited version of what I sent my manager after the meeting. I would welcome any discussion of my comments. In particular, what did I miss or misunderstand? I'm a novice at Zope, so I'm sure that there is a lot I don't know, such as what prepackaged zope tools are there for dealing with workflow, cookies, browser detection and user tracking? How hard are they to implement from scratch? We'll be making a decision real soon and I need every bit of info I can get. --Michael It appears to me that Zope and StoryServer have essentially the same capabilities. StoryServer appears to be Tcl based (at least the scripting language is Tcl based) whereas Zope is Python. The object oriented nature of Python may make it more powerful, but also, perhap, more confusing at the beginning. The StoryServer scripting seemed rather fragile to me--little happens automatically (see below for a discussion of flushing the cache) or by default. The Zope concept of "acquisition" operates very powerfully. If I had to redo a site I'd rather use Zope. StoryServer has a very clever caching mechanism. They cache components in the native filesystem, then let Apache's server-side include mechanism compose the files. (It wasn't clear to me how they manage to track users paths if the user only goes to cached files, so it is possible that they always have some communication overhead--I'm not sure.) The Zope cache is inside the Zserver, so probably a little slower. OTOH, when a Zope object changes it automatically notifies the cache, whereas the StoryServer cache needs to be explicitly flushed. When the cache is not in use StoryServer appears quite slow. Even with the cache they only claimed 1M hits/day using a dual CPU Ultra 2 sparc, which sounds much less than Zope. StoryServer appears to have much more "out-of-the-box" capabilities, though it is not clear to me whether that is only appearance, or reality. For instance, StoryServer has canned tools for workflow, cookie management, detection of browser versions, and user tracking. (Of course, cookies and browser detection are not very difficult.) I'm sure that Zope can handle such tasks, but I don't know if such tools are already written or need to be done from scratch. For instance, I've heard Jim or Paul say that they know how to deal with cookies, but I'm not sure what the capabilities are. Where StoryServer really wins is in the interface. They have a nice, Java powered user interface that provides a point and click method of both writing code, and administering the site. One big example is workflow. StoryServer has a nice system for moving content around, starting with the initial content entry, then through reviews by e.g. marketing, legal, etc., until it is finally published. All of this is configurable and doable though a nice GUI interface. I have confidence that Zope has the capability to perform all these tasks, but expect that is must be programmed from scratch. In any case, there is no fancy GUI for doing this under Zope. Most of the other differences pointed out by Vignette are FUD, but just because it is FUD doesn't mean it isn't true. It would be nice to know of a high volume, high visibility Zope powered site. StoryServer is a more mature product. Many (most) of its advantages are in the user interface area. People on the zope list have been talking about implementing things to close the user interface gap (dreamweaver, webDAV, java UIs, mozilla). When/if that happens StoryServer will have little advantage. (There is an additional danger of being stuck in the gui tools. If you business model doesn't fit the preprogrammed one in the tools you are out of luck.) Zope is a new product and still a little rough to use, but the power of it is clear. StoryServer has nothing at all like acquisition, nothing happens automatically, and there are no inherited properties. Every page has to explicitly define its behavior. One saving grace for StoryServer is that it caches "components", i.e. parts of a page (thing of, say, a navigation bar). If one component on a page changes only that component needs to be updated. Of course, it needs to explicitly clear the cache when it changes. Typically, the cache is cleared via a cron type of job even few minutes. The ability of a Zope object to invalidate the cache automatically is very nice. --Michael
Oops sorry about the last post by me -- that was an accident. I was intending to mention in that message interesting work on workflow by the multi-university Vela project. I would like a workflow system that is more abstract than the domain specific "moving Web development projects" down the pipeline. The NCSU folks have been developing an interesting system called Omniflow for general collaborative design. Now they make use of the tclet plugin on the client side, but one could imagine this in Java. I think there are some good ideas in what they are doing. I am doing something similar (but much simpler) in Zope using tclets for client side currently. See: http://www.cbl.ncsu.edu/demos/dac99/1999-EETimes-vela.pdf and demos (requires the tcl plugin) at: http://www.cbl.ncsu.edu/demos/dac99/ FYI Albert
Michael Hirsch wrote:
<stuff deleted>
What is clear to me is that Vignette has much better marketing. As a developer, I really liked the fairly technical discussion I had a Digital creations. We talked a lot about _how_ Zope does what it does, but not much about _what_ it can do. Vignette had a pretty good canned presentation of the many things is can do, but very little discussion of how it works.
<stuff deleted>
Below I've put an edited version of what I sent my manager after the meeting. I would welcome any discussion of my comments. In particular, what did I miss or misunderstand? I'm a novice at Zope, so I'm sure that there is a lot I don't know, such as what prepackaged zope tools are there for dealing with workflow, cookies, browser detection and user tracking? How hard are they to implement from scratch? We'll be making a decision real soon and I need every bit of info I can get.
Have you taken a look at KM|Net News? http://www.zope.org/Members/tazzzzz/kmnn It's got a basic workflow model for creating C|Net type news sites (which is where Vignette Storyserver comes from anyway). As it's built on Zope, you can customize it to your hearts content. To see how C|Net uses Storyserver check this link: http://builder.com/Business/HowCnet/index.html Also, take a look at Squishdot, http://www.squishdot.org , it is another news site type package, but one that focuses on user participation (modeled on http://www.slashdot.org). What are your sites requirements? The maintainers of both Zope news site products welcome patches and feature requests, how responsive is Vignette going to be to your needs? I could be wrong, But I beleive that although Python is not as popular a language as Perl, and therefore it is more dificult to find Python developers, TCL developers are even more dificult to find. For another perspective on Vignette Storyserver check out this link: http://www.photo.net/wtr/vignette.html HTH, Michael Bernstein.
participants (4)
-
albert boulanger -
Michael Bernstein -
Michael Hirsch -
Sascha Matzke