Eric Roby wrote:
Chris McDonough Wrote:
CatalogAware is arguably broken and should really not be used.
In the meantime, if you care at all about cataloging, do not use CatalogAware. Instead, manage the recataloging yourself and don't uncatalog a changed object before recataloging it during this manual operation, because this defeats all of the carefully set up change detection code (which may or may not still be working since I last worked on it ;-)
Chris,
Thank you for your candor here. I wish this minor detail had been disclosed in the Zope book. Chapter 9 was my holy grail when I started down this trail (creating these new ZClasses that would auto catalog themselves). It looked good in print... I have banked a good deal of my project on this very service and ... well it is a bit frustrating to find out that I need to go back and re-do my work.
Well.. actually, it's pretty simple to change CatalogAware to work better for you. With a little thought, CatalogAware could be hacked at your end to be sane for your application. You needn't rewrite all your code. It's just hard for DC to release a perfect CatalogAware that works better and is completely backwards-compatible. It's much harder to change it to work perfectly for everybody (which is our job here ;-) than to change it to work perfectly for a particular application. Basically, change the reindex_object method to: self.index_object() Instead of: self.unindex_object() self.index_object() That makes CatalogAware much saner and will produce less bloat. Actually, maybe I should just go make that change in the trunk and the 2.4 branch, although I'm a little afraid of what (if anything) it will break for everybody. To be honest, I really don't have much time to spend thinking about this, and my fears are probably just FUD.
Along this same vein, I would suggest that (possibly) ZClasses don't really work, either, "and should not be used". There was a comment from another developer (on zope-dev a month or so ago) that essentially (in his own words) made this very claim. At the time, I chalked it up to this "Real Zope Developers Don't Use ZCLasses" kinda comment. There certainly are enough Zope products out there that (at least) leverage some of the ZClass plumbing.
Well, I dont use ZClasses much. But that's because I like to use Emacs.
Another claim in the Zope book (chapter 8) says that I can leverage my 6+ years of Perl experience to create Zope scripts. Well, I would suggest that this doesn't really work, either...
Not sure what you mean by doesnt work, but I assume you've had an unpleasant experience with zope-perl?
The bottom line to all this venting (and I am not trying to shoot the messenger here) is that I need to understand where my efforts should be focused. If I need to abandon ZClasses in lieu of pure Python, then I need to know that now so I don't waste any more time on these false starts. The
I'll go out on a limb here. You should learn how to write Python Products if you're serious about creating reusable Zope applications. There.
Perl thing is just a matter of principle (I think Perl's implementation of OO stinks). The way it is presented in the book, I would expect it to be a core Zope thing and not some appendage that requires a particular compiler and Andy sitting next to you.
I've sort of enjoyed myself on all the times when Andy has been sitting near me, but I understand. ;-) Jim had a bad experience installing zope-perl lately. I wish I could help. Strangely, myself, I had few problems getting it installed and working fine. Maybe I'm just lucky. I actually think zope-perl is sort of an engineering marvel myself.
I don't intend to abandon Zope, I just need a reality check...
HTH, - C