2009/2/11 Laurent Mignon <laurent.mig...@softwareag.com>:
> 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

Yeah. So one solution, as I said before is to release zope.sitecompat
egg that provides a "zope.site" module, but doesn't implement a site
implementation, but instead imports things from old zope.app.component
(as does the new zope.app.component reversely). The same thing could
be done for zope.browser. However, this is an ugly solution, so I hope
Zope2 will move to eggs completely soon, so we won't have to deal with
problems like that.

WBR, Dan Korostelev
Zope-Dev maillist  -  Zope-Dev@zope.org
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope )

Reply via email to