Martin Aspeli wrote at 2007-1-9 20:48 +:
- It's an explicit declaration of support
As is the definition of __of__.
Well, not in a formal sense. I could have some non-Zope python object
that I wanted to register as a local utility (to override a global one,
say) that could have
Dieter Maurer wrote:
- It's an explicit declaration of support
As is the definition of __of__.
Well, not in a formal sense. I could have some non-Zope python object
that I wanted to register as a local utility (to override a global one,
say) that could have __of__() for some other
Tres Seaver wrote:
Or, to paraphrase the Beatles: All you need is __of__ ... DAH dah,
dadda dum... __of__ is all you need.
LOL! :)
Knock yourselves out, I don't feel as strongly about this as I like a
good argument. ;)
Martin
___
Zope-CMF
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 8 Jan 2007, at 01:19, Hanno Schlichting wrote:
Right now I would let all existing CMF tools implement that interface,
so we would be on the safe side. In a later release we can revisit
this
and see if some tools don't need Acquisition to work
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jens Vagelpohl wrote:
On 8 Jan 2007, at 01:19, Hanno Schlichting wrote:
Right now I would let all existing CMF tools implement that interface,
so we would be on the safe side. In a later release we can revisit
this
and see if some tools don't
Tres Seaver wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jens Vagelpohl wrote:
On 8 Jan 2007, at 01:19, Hanno Schlichting wrote:
Right now I would let all existing CMF tools implement that interface,
so we would be on the safe side. In a later release we can revisit
this
and see if
Hanno Schlichting wrote at 2007-1-7 23:42 +0100:
Thus, the proposal exhibits an essential example that local
utilities should be returned acquisition wrapped (if the have an '__of__'
method).
Maybe a compromise would be to only return those utilities back
acquisition wrapped that where
Martin Aspeli wrote at 2007-1-7 23:40 +:
...
Why not do it a more Zope3 ish way:
class ICMFTool(Interface):
Marker for any CMF tool
and then in the subclass of the local component registry:
local_utility =
if ICMFTool.providedBy(local_utility):
local_utility =
Martin Aspeli wrote:
Philipp von Weitershausen wrote:
Actually, I agree with Dieter here. If something has an __of__(), just
wrap it. You can't possibly do anything wrong, actually, as it already
happens and it provides the best backward compatibility with what we
have right now.
Is
Jens Vagelpohl wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 6 Jan 2007, at 23:03, Martin Aspeli wrote:
In light of what we're seeing here, and because there is *so* much
third party code using getToolByName(), perhaps a
DeprecationWarning (and worse, speedy deprecation) is a bit
Am 07.01.2007 um 14:26 schrieb Martin Aspeli:
However, surely, if we agree that it's premature to do so,
commenting out the line that sends a DeprecationWarning won't be
much of a change?
That's just plain silly! The warning is the best way of informing
developers: explicit is better
Jens Vagelpohl wrote:
On 7 Jan 2007, at 14:26, Martin Aspeli wrote:
I didn't realise we would fully deprecate getToolByName() quite yet,
though. I must admit I haven't been following your checkins, for lack
of time (and since you're surely more qualified than me in this work
in any case).
Hi Jens,
Jens Vagelpohl wrote:
- I'll be happy to mark those places in the code where I had to
manually wrap after a straight getUtility/queryUtility call so these
places stand out as a reminder to do something about it.
I haven't marked those places yet, but attached you can find a patch
Martin Aspeli wrote at 2007-1-6 22:06 +:
Hanno Schlichting wrote:
The idea is to use a specialized persistent component registry, that
does the needed AQ-wrapping.
This will however only give us AQ-wrapped local utilities, whereas those
registered with the global component registry
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 7 Jan 2007, at 23:09, Martin Aspeli wrote:
I fully agree with this (going ahead with the work), it's just a
question of whether we want to fill people's error logs with
warnings or not. Perhaps we could start off at a lower error level
for
Dieter Maurer wrote:
Martin Aspeli wrote at 2007-1-6 22:22 +:
- Registering the portal as a utility that can be obtained by
getUtility(IPortalRoot) is pretty good practice; in my estimation, that
should solve all the use cases for utilities where acquisition is used
now and
Hi Jens,
A warning is a warning is a warning, there's no lower level, and
people won't see anything if it isn't in their faces. The usage of
something like a debug error message is unprecedented,
counterintuitive and will not compel anyone to fix their product. We
finally have a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 7 Jan 2007, at 23:45, Martin Aspeli wrote:
A warning is of course one thing. If getToolByName() is gone
entirely in a year (I don't know if that was your intention or not)
it's pretty scary. Surely, some things deserve longer deprecation
Hanno Schlichting wrote:
Maybe a compromise would be to only return those utilities back
acquisition wrapped that where registered as tools?
That sounds sensible to me; most new local utilities wouldn't really
behave the same way, I'm guessing.
Jens added a new function to CMFCore.utils
Martin Aspeli wrote:
Jens Vagelpohl wrote:
Let's talk about something fun instead, like that wrapping issue. I
personally can't see any problem with Hanno's suggestion for a
special component registry and automatically wrapping those tools
that are in the little registry. I'm just
Jens Vagelpohl wrote:
On 6 Jan 2007, at 12:57, Andreas Jung wrote:
On 5 Jan 2007, at 20:51, Andreas Jung wrote:
I finished my work (including some test).
Any objections merging the changes back to the trunk?
If the tests pass, no. At least from me ;)
I merged the changes... hopefully
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 6 Jan 2007, at 15:34, Hanno Schlichting wrote:
I had to change two things in CMF so far though. Here are the
patches I
came up with:
Thanks Hanno, this is a point I wanted to bring up after getting the
last work done: When using
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 6 Jan 2007, at 16:03, Martin Aspeli wrote:
I would say it's very bad if we need to train people on when aq-
wrapping tools (using __of__() say) is required and when it's not.
In fact, I'd say its catastrophic and will break incredible amounts
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Rocky Burt wrote:
On Sat, 2007-06-01 at 16:32 +0100, Hanno Schlichting wrote:
Hhm, I'm not sure what the best way is here. Personally I would like to
get rid of as much of Acquisition as possible, but obviously we need to
be careful here.
+10
Martin Aspeli wrote:
Jens Vagelpohl wrote:
My concern is just that we need a robust solution that doesn't put too
much onus on the end developer. If I have to do this it's pretty
horrendous:
mtool = getUtility(IMembershipTool)
mtool = mtool.__of__(context)
# now use mtool
Hanno Schlichting wrote:
Yep, you are wrong ;)
Fair enough. Out of curiosity, does the object have a __parent__?
In any case, I think your original suggestion is a good one. Let's take
this opportunity to diagnose the problem and not the symptom: True
tools should be singletons and act
Hanno Schlichting wrote:
PhiliKON some time ago suggested that Five should wrap the utilities
eventually but nobody followed up on that idea.
Philipp also has some ideas (not too far off completion, I believe) that
may remove some of the acquisition intermingling. I'm not sure they'd
apply
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 6 Jan 2007, at 21:49, Martin Aspeli wrote:
Also, getToolByName remains and is almost certainly the way forward
for all TTW code still, because it lets us aq wrap, it removes the
need to make all interfaces importable in untrusted code, and it
Hanno Schlichting wrote:
The idea is to use a specialized persistent component registry, that
does the needed AQ-wrapping.
This will however only give us AQ-wrapped local utilities, whereas those
registered with the global component registry wouldn't be wrapped. I
think this might be an
Okay, spoke to Philipp on IRC and he asked me to relay his opinions on
some of this:
- CMF tools ought not to depend on acquiring things from 'self' if at
all possible.
- TTW code will need aq contexts for security. However, it makes sense
for getToolBy(Interface)Name() to handle this.
Hanno Schlichting wrote:
Martin Aspeli wrote:
Hanno Schlichting wrote:
PhiliKON some time ago suggested that Five should wrap the utilities
eventually but nobody followed up on that idea.
Philipp also has some ideas (not too far off completion, I believe) that
may remove some of the
31 matches
Mail list logo
