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
_______________________________________________
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )