Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Zope: CMF

[dev] Should portal_setup be registered as utility?

 

 

Zope cmf RSS feed   Index | Next | Previous | View Threaded


y.2008 at wcm-solutions

Nov 16, 2008, 7:17 AM

Post #1 of 21 (1716 views)
Permalink
[dev] Should portal_setup be registered as utility?

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 bug:
https://bugs.launchpad.net/zope-cmf/+bug/263525

Due to a misunderstanding the CMF bug was marked as 'Won't Fix'.


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?


Cheers,

Yuppie


_______________________________________________
Zope-CMF maillist - Zope-CMF[at]lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests


charlie at begeistert

Nov 16, 2008, 7:32 AM

Post #2 of 21 (1666 views)
Permalink
Re: [dev] Should portal_setup be registered as utility? [In reply to]

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 this year? last year?) on
which tools should be moved to utilities?

I fully support Jens' justification of the utility approach. Things
are a bit weird at the moment with some things still being tools and
others utilities but once I got used to the utility approach I found
it saner.

I don't think that we can support both approaches and if Plone needs a
wrapper around the utility with access to the request object then
surely that is something for Plone?

Charlie
--
Charlie Clark
Helmholtzstr. 20
Düsseldorf
D- 40215
Tel: +49-211-938-5360
GSM: +49-178-782-6226



_______________________________________________
Zope-CMF maillist - Zope-CMF[at]lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests


hannosch at hannosch

Nov 16, 2008, 8:23 AM

Post #3 of 21 (1667 views)
Permalink
Re: [dev] Should portal_setup be registered as utility? [In reply to]

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 issue was reported as CMF bug:
> https://bugs.launchpad.net/zope-cmf/+bug/263525
>
> Due to a misunderstanding the CMF bug was marked as 'Won't Fix'.
>
> 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 tool as an utility anymore,
is that too many import/export steps in-the-wild required the REQUEST to
be available.

In general we removed the tool as utility registrations for all tools
where a request was still required. We'd like to put those back only
after the request is really not used anymore i.e. after the code has
been adjusted - not force any code to be changed due to the utility
registration.

I'd prefer the portal_setup tool utility registration to be removed again.

Hanno

_______________________________________________
Zope-CMF maillist - Zope-CMF[at]lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests


wichert at wiggy

Nov 16, 2008, 8:59 AM

Post #4 of 21 (1664 views)
Permalink
Re: [dev] Should portal_setup be registered as utility? [In reply to]

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:
> > http://dev.plone.org/plone/ticket/7714
> >
> > The same issue was reported as CMF bug:
> > https://bugs.launchpad.net/zope-cmf/+bug/263525
> >
> > Due to a misunderstanding the CMF bug was marked as 'Won't Fix'.
> >
> > 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 tool as an utility anymore,
> is that too many import/export steps in-the-wild required the REQUEST to
> be available.

Specifically the problem is that import/export steps use tools which for
whatever reason assume self.REQUEST is available.

WIchert.

--
Wichert Akkerman <wichert[at]wiggy.net> It is simple to make things.
http://www.wiggy.net/ It is hard to make things simple.
_______________________________________________
Zope-CMF maillist - Zope-CMF[at]lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests


wichert at wiggy

Nov 16, 2008, 9:02 AM

Post #5 of 21 (1662 views)
Permalink
Re: [dev] Should portal_setup be registered as utility? [In reply to]

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?
>
>
> Does this relate to the discussions (earlier this year? last year?) on
> which tools should be moved to utilities?
>
> I fully support Jens' justification of the utility approach. Things
> are a bit weird at the moment with some things still being tools and
> others utilities but once I got used to the utility approach I found
> it saner.
>
> I don't think that we can support both approaches and if Plone needs a
> wrapper around the utility with access to the request object then
> surely that is something for Plone?

The problem is not Plone: the problem is that the setup tool invokes
import and export steps, which themselves can do any random thing.
Unfortunately in the Zope 2 world a lot of those random things still
expect self.REQUEST to be available. If you get the GS setup tool
via getUtility that is not true and you see unexpected things breaking.
That is why for Plone we decided to not register the setup tool as a
utility until we can be sure that none of the standard tools need
self.REQUEST or have utility-based variant.

Wichert.

--
Wichert Akkerman <wichert[at]wiggy.net> It is simple to make things.
http://www.wiggy.net/ It is hard to make things simple.
_______________________________________________
Zope-CMF maillist - Zope-CMF[at]lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests


y.2008 at wcm-solutions

Nov 16, 2008, 9:11 AM

Post #6 of 21 (1664 views)
Permalink
Re: [dev] Should portal_setup be registered as utility? [In reply to]

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 tool as an utility anymore,
> is that too many import/export steps in-the-wild required the REQUEST to
> be available.

Are there use cases where the REQUEST is required or is this 'just' a
backwards compatibility issue?

> In general we removed the tool as utility registrations for all tools
> where a request was still required. We'd like to put those back only
> after the request is really not used anymore i.e. after the code has
> been adjusted - not force any code to be changed due to the utility
> registration.

How do you encourage people to adjust their import/export steps? People
will write new steps that depend on REQUEST if there are no deprecation
warnings.

> I'd prefer the portal_setup tool utility registration to be removed again.

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?

I don't like to remove CMF's portal_setup registration *if* CMF itself
is not affected by this issue.

Cheers, Yuppie

_______________________________________________
Zope-CMF maillist - Zope-CMF[at]lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests


jens at dataflake

Nov 16, 2008, 12:57 PM

Post #7 of 21 (1660 views)
Permalink
Re: [dev] Should portal_setup be registered as utility? [In reply to]

-----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)

iEYEARECAAYFAkkgiUwACgkQRAx5nvEhZLIhEQCdEkuvKVD02TAwCbK0zfPAWqcK
RYUAmgLCUroC7XUanE7wxnTNG/sii6MS
=nO8h
-----END PGP SIGNATURE-----
_______________________________________________
Zope-CMF maillist - Zope-CMF[at]lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests


wichert at wiggy

Nov 16, 2008, 1:30 PM

Post #8 of 21 (1658 views)
Permalink
Re: [dev] Should portal_setup be registered as utility? [In reply to]

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?
>
> 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 any CMF tool uses
self.REQUEST is problematic since it makes it impossible for
import/export steps to use such tools.

Wichert.

--
Wichert Akkerman <wichert[at]wiggy.net> It is simple to make things.
http://www.wiggy.net/ It is hard to make things simple.
_______________________________________________
Zope-CMF maillist - Zope-CMF[at]lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests


wichert at wiggy

Nov 16, 2008, 1:30 PM

Post #9 of 21 (1657 views)
Permalink
Re: [dev] Should portal_setup be registered as utility? [In reply to]

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?
>
> 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 any CMF tool uses
self.REQUEST is problematic since it makes it impossible for
import/export steps to use such tools.

Wichert.

--
Wichert Akkerman <wichert[at]wiggy.net> It is simple to make things.
http://www.wiggy.net/ It is hard to make things simple.
_______________________________________________
Zope-CMF maillist - Zope-CMF[at]lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests


charlie at begeistert

Nov 16, 2008, 1:55 PM

Post #10 of 21 (1659 views)
Permalink
Re: [dev] Should portal_setup be registered as utility? [In reply to]

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 move
to utilites.

Charlie
--
Charlie Clark
Helmholtzstr. 20
Düsseldorf
D- 40215
Tel: +49-211-938-5360
GSM: +49-178-782-6226



_______________________________________________
Zope-CMF maillist - Zope-CMF[at]lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests


jens at dataflake

Nov 16, 2008, 2:05 PM

Post #11 of 21 (1663 views)
Permalink
Re: [dev] Should portal_setup be registered as utility? [In reply to]

-----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 any CMF tool
> uses
> self.REQUEST is problematic since it makes it impossible for
> import/export steps to use such tools.


I suggest we *look* at the current CMF situation before acting on the
assumption that non-utility tools are used in (and break) CMF import/
export steps. It's been working fine so far.

jens



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkkgmSsACgkQRAx5nvEhZLJxSACeJmQUFUNTjayJYLsSRIAolcpz
RZwAnjEu4F9Lc6IbTsklEkXpbKgHPfkI
=6vSX
-----END PGP SIGNATURE-----
_______________________________________________
Zope-CMF maillist - Zope-CMF[at]lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests


wichert at wiggy

Nov 16, 2008, 11:21 PM

Post #12 of 21 (1645 views)
Permalink
Re: [dev] Should portal_setup be registered as utility? [In reply to]

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 any CMF tool
> > uses
> > self.REQUEST is problematic since it makes it impossible for
> > import/export steps to use such tools.
>
>
> I suggest we *look* at the current CMF situation before acting on the
> assumption that non-utility tools are used in (and break) CMF import/
> export steps. It's been working fine so far.

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.

Wichert.

--
Wichert Akkerman <wichert[at]wiggy.net> It is simple to make things.
http://www.wiggy.net/ It is hard to make things simple.
_______________________________________________
Zope-CMF maillist - Zope-CMF[at]lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests


dieter at handshake

Nov 17, 2008, 11:43 AM

Post #13 of 21 (1644 views)
Permalink
Re: [dev] Should portal_setup be registered as utility? [In reply to]

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 application framework.
Obviously, the request is quite important for many tasks related
to Web processing.

Zope3 may have other, cleaner ways to access the request.
But Zope2 has just two ways -- explicit passing and request access
via the acquisition context.
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?

If they would, local utilities were much nearer to tools and
the transition would be facilitated.


--
Dieter
_______________________________________________
Zope-CMF maillist - Zope-CMF[at]lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests


y.2008 at wcm-solutions

Nov 18, 2008, 3:00 AM

Post #14 of 21 (1639 views)
Permalink
Re: [dev] Should portal_setup be registered as utility? [In reply to]

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 request boundaries. AFAICT it would
have been necessary to rewrite the registry code completely to make sure
we return always the right request.

> 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 really be a win.


Cheers,

Yuppie

_______________________________________________
Zope-CMF maillist - Zope-CMF[at]lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests


optilude at gmx

Nov 18, 2008, 8:25 AM

Post #15 of 21 (1637 views)
Permalink
Re: [dev] Should portal_setup be registered as utility? [In reply to]

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
> code caches the utilities across request boundaries. AFAICT it would
> have been necessary to rewrite the registry code completely to make sure
> we return always the right request.
>
>> 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 really be a win.

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 in the same way that it sets the site
manager (so you can get it via getSite()). Calling getRequest() would in
many ways be cleaner than doing self.context.REQUEST or whatever, and
would work regardless of whether the context was acquisition wrapped.

Cheers
Martin

--
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book

_______________________________________________
Zope-CMF maillist - Zope-CMF[at]lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests


dieter at handshake

Nov 19, 2008, 10:47 AM

Post #16 of 21 (1632 views)
Permalink
Re: [dev] Should portal_setup be registered as utility? [In reply to]

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
>code caches the utilities across request boundaries. AFAICT it would
>have been necessary to rewrite the registry code completely to make sure
>we return always the right request.
>
>> 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 really be a win.

Then, maybe, Zope 3 utilities are inadequate at many places in
to Zope 2 world: e.g. any tool that uses TALES expressions may
want to access the (current, of course) request -- especially
when they are destined for user interaction (as actions are).

In view of this, one can understand that Plone has problems with
the "setup_tool" utility registration.



--
Dieter
_______________________________________________
Zope-CMF maillist - Zope-CMF[at]lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests


dieter at handshake

Nov 19, 2008, 10:50 AM

Post #17 of 21 (1631 views)
Permalink
Re: [dev] Should portal_setup be registered as utility? [In reply to]

Martin Aspeli wrote at 2008-11-18 16:25 +0000:
> ...
>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 in the same way that it sets the site
>manager (so you can get it via getSite()). Calling getRequest() would in
>many ways be cleaner than doing self.context.REQUEST or whatever, and
>would work regardless of whether the context was acquisition wrapped.

That, too, would be a solution to access the often needed request --
just not the typical Zope2 one: i.e. lots of rewrites would be necessary.



--
Dieter
_______________________________________________
Zope-CMF maillist - Zope-CMF[at]lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests


me at rpatterson

Nov 19, 2008, 11:33 AM

Post #18 of 21 (1633 views)
Permalink
Re: [dev] Should portal_setup be registered as utility? [In reply to]

Martin Aspeli <optilude[at]gmx.net> 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 first. But it turned out that Zope 3's site manager
>> code caches the utilities across request boundaries. AFAICT it would
>> have been necessary to rewrite the registry code completely to make sure
>> we return always the right request.
>>
>>> 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 really be a win.
>
> 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 in the same way that it sets the site
> manager (so you can get it via getSite()). Calling getRequest() would in
> many ways be cleaner than doing self.context.REQUEST or whatever, and
> would work regardless of whether the context was acquisition wrapped.

+100

Ross

_______________________________________________
Zope-CMF maillist - Zope-CMF[at]lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests


y.2008 at wcm-solutions

Nov 20, 2008, 3:42 AM

Post #19 of 21 (1617 views)
Permalink
Re: [dev] Should portal_setup be registered as utility? [In reply to]

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 really be a win.
>
> Then, maybe, Zope 3 utilities are inadequate at many places in
> to Zope 2 world: e.g. any tool that uses TALES expressions may
> want to access the (current, of course) request -- especially
> when they are destined for user interaction (as actions are).

I agree. Utilities are inadequate for user interaction. Views should be
used instead.

We don't need the request for managing TALES expressions inside an
utility. The request is only needed if we *use* the expressions, and
that should be done in view code, not in utilities.

Several tool methods have to be replaced by view code before we can
register all tools as utilities.

> In view of this, one can understand that Plone has problems with
> the "setup_tool" utility registration.

The setup tool is responsible for managing configuration data. I can't
see a need to care about the request in that context.

Cheers, Yuppie

_______________________________________________
Zope-CMF maillist - Zope-CMF[at]lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests


charlie at begeistert

Nov 20, 2008, 11:33 AM

Post #20 of 21 (1607 views)
Permalink
Re: [dev] Should portal_setup be registered as utility? [In reply to]

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 understand that Plone has problems with
>> the "setup_tool" utility registration.
>
> The setup tool is responsible for managing configuration data. I can't
> see a need to care about the request in that context.


Agreed. If third party tools have problems, then they should provide
the solutions.

Charlie
--
Charlie Clark
Helmholtzstr. 20
Düsseldorf
D- 40215
Tel: +49-211-938-5360
GSM: +49-178-782-6226



_______________________________________________
Zope-CMF maillist - Zope-CMF[at]lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests


dieter at handshake

Nov 23, 2008, 12:00 AM

Post #21 of 21 (1558 views)
Permalink
Re: [dev] Should portal_setup be registered as utility? [In reply to]

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 solutions. Therefore, they changed their CMF version
to give third parties more time to adapt to a more Zope 3 style
of doing things (e.g. accessing request only on code paths specifically
designed for request processing).

Note, that not everybody finds a more Zope 3 style of doing a worth
in itself -- with corresponding reluctance to change something just
for this purpose.



--
Dieter
_______________________________________________
Zope-CMF maillist - Zope-CMF[at]lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Zope cmf RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact lists@gossamer-threads.com
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.