Charlie Clark wrote at 2008-11-20 20:33 +0100:
> ...
>Agreed. If third party tools have problems, then they should provide
>the solutions.
The Plone people are much more open to integrate third party solutions
(a good thing in principle). But, they have only limited control
over third party solu
Am 20.11.2008 um 12:42 schrieb yuppie:
> Several tool methods have to be replaced by view code before we can
> register all tools as utilities.
It's already on my radar as soon as I get some time to catch my breath
(and complete my two other minor tasks first!)
>> In view of this, one can und
Dieter Maurer wrote:
> yuppie wrote at 2008-11-18 12:00 +0100:
>> Dieter Maurer wrote:
>>> If they would, local utilities were much nearer to tools and
>>> the transition would be facilitated.
>> They would be nearer to tools, but also more distant from zope 3
>> utilities. I doubt that would real
Martin Aspeli <[EMAIL PROTECTED]> writes:
> yuppie wrote:
>> Hi Dieter!
>>
>>
>> Dieter Maurer wrote:
>>> Thus, why do local utilities registered by Five (i.e. these utilities are
>>> for Zope2 use) do not provide access to the request in the normal
>>> Zope2 way?
>>
>> That's what we tried fir
Martin Aspeli wrote at 2008-11-18 16:25 +:
> ...
>This won't solve this particular problem, but it may be worth looking at
>how other frameworks work. Pylons, for example, has the request
>available as "global" variable - actually a thread-local. Zope could set
>the request as a thread local
yuppie wrote at 2008-11-18 12:00 +0100:
>Dieter Maurer wrote:
>> Thus, why do local utilities registered by Five (i.e. these utilities are
>> for Zope2 use) do not provide access to the request in the normal
>> Zope2 way?
>
>That's what we tried first. But it turned out that Zope 3's site manager
yuppie wrote:
> Hi Dieter!
>
>
> Dieter Maurer wrote:
>> Thus, why do local utilities registered by Five (i.e. these utilities are
>> for Zope2 use) do not provide access to the request in the normal
>> Zope2 way?
>
> That's what we tried first. But it turned out that Zope 3's site manager
> co
Hi Dieter!
Dieter Maurer wrote:
> Thus, why do local utilities registered by Five (i.e. these utilities are
> for Zope2 use) do not provide access to the request in the normal
> Zope2 way?
That's what we tried first. But it turned out that Zope 3's site manager
code caches the utilities across
Wichert Akkerman wrote at 2008-11-17 08:21 +0100:
> ...
>I'm sure CMF import/export steps are fine. The CMF tools are not, and
>third party products use those in their steps. That is exactly the
>problem we where seeing in Plone, and which is why I removed the utility
>registration.
Zope is a Web
Previously Jens Vagelpohl wrote:
> On Nov 16, 2008, at 22:30 , Wichert Akkerman wrote:
> > Previously yuppie wrote:
> >> I don't like to remove CMF's portal_setup registration *if* CMF
> >> itself
> >> is not affected by this issue.
> >
> > Imho registering portal_setup as a utility as long as an
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Nov 16, 2008, at 22:30 , Wichert Akkerman wrote:
> Previously yuppie wrote:
>> I don't like to remove CMF's portal_setup registration *if* CMF
>> itself
>> is not affected by this issue.
>
> Imho registering portal_setup as a utility as long as
Am 16.11.2008 um 22:30 schrieb Wichert Akkerman:
> Imho registering portal_setup as a utility as long as any CMF tool
> uses
> self.REQUEST is problematic since it makes it impossible for
> import/export steps to use such tools.
Surely, that's what deprecation messages are for? We do want to m
Previously yuppie wrote:
> I'm not sure if the import/export steps used by CMF are clean or if
> nobody recognized the issue because nobody runs import/export steps from
> a portal_setup tool that was looked up as utility. Maybe the issue just
> shows up in combination with portal_quickinstall?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Nov 16, 2008, at 18:11 , yuppie wrote:
> I don't like to remove CMF's portal_setup registration *if* CMF itself
> is not affected by this issue.
+1
jens
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (Darwin)
iEYEARECAAYFAkkgiUwACgkQRAx
Hanno Schlichting wrote:
> yuppie wrote:
>> Questions: Is there a good reason why Plone doesn't register
>> portal_setup as utility? Does the same reason apply to CMFDefault? Do we
>> have to support registered and not registered portal_setup tools?
>
> The reason why we don't register the setup
Previously Charlie Clark wrote:
>
> Am 16.11.2008 um 16:17 schrieb yuppie:
>
> > Questions: Is there a good reason why Plone doesn't register
> > portal_setup as utility? Does the same reason apply to CMFDefault?
> > Do we
> > have to support registered and not registered portal_setup tools?
>
Previously Hanno Schlichting wrote:
> yuppie wrote:
> > CMFDefault registers portal_setup as utility. Some code in CMF depends
> > on that.
> >
> > Plone doesn't doesn't register portal_setup as utility:
> > http://dev.plone.org/plone/changeset/18763
> >
> > That causes some trouble in Plone:
>
yuppie wrote:
> CMFDefault registers portal_setup as utility. Some code in CMF depends
> on that.
>
> Plone doesn't doesn't register portal_setup as utility:
> http://dev.plone.org/plone/changeset/18763
>
> That causes some trouble in Plone:
> http://dev.plone.org/plone/ticket/7714
>
> The same
Am 16.11.2008 um 16:17 schrieb yuppie:
> Questions: Is there a good reason why Plone doesn't register
> portal_setup as utility? Does the same reason apply to CMFDefault?
> Do we
> have to support registered and not registered portal_setup tools?
Does this relate to the discussions (earlier t
Hi!
CMFDefault registers portal_setup as utility. Some code in CMF depends
on that.
Plone doesn't doesn't register portal_setup as utility:
http://dev.plone.org/plone/changeset/18763
That causes some trouble in Plone:
http://dev.plone.org/plone/ticket/7714
The same issue was reported as CMF b
20 matches
Mail list logo
