Philipp von Weitershausen wrote:
Dieter Maurer wrote:
yuppie wrote at 2007-2-3 11:44 +0100:
Unfortunately integrating a product into the Zope core means more
than just adjusting the coding style:
- As already mentioned in this thread, monkey patches and code like
fixPluginIndexes.py have to be resolved. AdvancedQuery contains a
monkey patch for CMF - that should not be shipped with Zope core.
"fixPluginIndexes" fixed (maybe meanwhile resolved) bugs in
The mentioned CMF monkey patch gives the "CatalogTool" the new method
"evalAdvancedQuery", provided CMFCore is installed.
I do not see why this monkey patch should not be applied.
I am sure that I want to be able to use "AdvancedQuery" even
with a "CatalogTool", if both are installed.
Monkey patches should be avoided when they can. I think that's something
we don't need to discuss. Integrating a product into Zope is the perfect
opportunity to get rid of monkey patches and consolidate the fixes into
the main product lines. Therefore, the CMF should rather grow that
method itself than having it patched in by Zope.
Either way, I think this point is mute since all the Plone community
really wants is a public subversion repository with access to the code
and "control over the code", which I would think is asking for a lot
(you've indicated that reformatting the code would mean you wouldn't be
available for maintenance anymore).
Whoever is asking for AdvancedQuery and other things to be in
svn.zope.org or even Zope 2 itself ought to weigh the amount of
maintenance work against the little potential (not actual!) benefits. I
think we can leave everything as it is and if Plone needs it in an svn
repo, heck, why not do vendor imports? (not in svn.zope.org, of course,
since the contributor agreement forbids that)
I'm not sure this warranted this much discussion or getting panties in a
bunch, but maybe something was learned here. As phrased early on, it
would be *nice* for those of us using svn:externals to manage certain
build processes to have AdvancedQuery in svn somewhere(not life or death).
did we reach some sort of conclusion in all this? Having a AQ egg would
be the same difference imho.
I would be happy to help maintain AdvancedQuery(though I hardly feel
qualified), though I would prefer to leave it in a form that Dieter
would actually want to work on it.
What might be more worthwile is to package AQ up to be an egg(I
volunteer for this). That way we could manage the dependency that
way(zope could too if it chose to ship with AQ), dieter could continue
maintaining AQ, and everything would be peachy.
one last point re: Zope: From a marketing perspective(to parrot slinkp),
I would think Zope 2 would want to include AdvancedQuery since it is a
go-to answer for lots of "how do I do sqlish query X in the ZODB" type
questions. Granted, hurry.query and the z3 catalogs have similar
capabilities, but AQ works right now with existing z2 catalogs.
------ d. whit morriss ------
- senior engineer, opencore -
- http://www.openplans.org -
- m: 415-710-8975 -
"If you don't know where you are,
you don't know anything at all"
Dr. Edgar Spencer, Ph.D., 1995
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -