Stephan Richter wrote:
On Wednesday 11 February 2009, Dan Korostelev wrote:
Thanks for getting our attention on this. I consider this a show-stopper for 2.0. Dan, let's think about something creative that allows us to use the new and old way, maybe through a special import statement like that: Is the problem in that zope2 still contains zope.* modules in itself and not in the eggs, so if it contain old zope.app.component and the new z3c.form depends on zope.site egg, we get two independent local site implementation that will conflict? If so, I guess we have the similar problem with ITerms that was moved to zope.browser.
Yes zope2 still contains zope.* modules BUT the plone.recipe.zope2install has an option 'fake-zope-eggs' to add fake egg links to Zope 3 libraries, so that setuptools can see and use them for dependencies lookup... zope2 (for my part I use zope-2.11.2) still contain and relay on zope.app.component. It's true that we have two independent local sites implementation since z3c.form depends of zope.site. I think that the only issue is when a call is made to the 'getSite' function provided by zope.site to request the site root. The function is only used 2 times in the code (ImageButtonAction and ImageFieldWidget) to compute the resource url. Since these two classes are registered as adapters, we can provide an override for zope2. (maybe into plone.z3cform...) I don't have a similar problem with ITerms since I've updated my code to use the ITerms provided by zope.browser. But, when I execute a 'grep' on the plone code itself, I found four potential issues: plone/app/form/widgets/uberselectionwidget.py plone/app/vocabularies/catalog.py plone/app/vocabularies/groups.py plone/app/vocabularies/users.py
I think they later reported this problem as fixed and they got it working in Zope 2. Right?
Regards, Stephan