Charlie Clark <char...@...> writes:
> Am 19.12.2008 um 10:48 schrieb Matt Hamilton:
> > Of course as soon as you find the problem, you then know how to ask
> > the
> > question...
> I think that sense of embarassment is an essential part of the
> > and in looking for opaqueitems, found that Helge has already got
> > there and started waving some performance pixie dust over it:
> > http://pypi.python.org/pypi/experimental.opaquespeedup
> > Still... I don't quite understand why CMF is doing what it is doing
> > in the first
> > place.
> They are containers which won't be picked up by the normal methods. I
> agree that the current practice of checking every attribute could be a
> little expensive if you have lots of child objects stored in
> attributes. I think the solution is probably to see if the problem
> that they were introduced to address can't be solved in a different
> manner. The discussion a couple of weeks ago about CMFCatalogAware
> suggested that this class does indeed need refactoring for more
> predictable behaviour.
The issue is it's not just finding the opaque objects but waking up all the
'normal' objects too. Hence it is looking in folders (which would already get
the event no doubt). I suppose the bit that really confuses me is why is a
BeforeTraverse event being handled and dispatched to these opaque objects by
code in CMFCatalogAware? My first thoughts when looking at the tracebacks in
pdb went something like 'OK I'm traversing, so a traversal event is fired...
wait a sec, why is CMFCatalogAware code being executed... I'm not indexing
Matt Hamilton ma...@netsight.co.uk
Netsight Internet Solutions, Ltd. Understand. Develop. Deliver
http://www.netsight.co.uk +44 (0)117 9090901
Web Design | Zope/Plone Development & Consulting | Co-location | Hosting
Zope-CMF maillist - Zope-CMF@lists.zope.org
See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests