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
"Products.PluginIndexes.common.util.parseIndexRequest".

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.

-w


--

------ 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
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )

Reply via email to