-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 15 Jan 2007, at 17:00, Rocky Burt wrote:
On Mon, 2007-08-01 at 15:40 +0100, Philipp von Weitershausen wrote:
Since Five is feature-frozen and new stuff should be added in Python
packages anyway, my suggestion is to put this thing into a
five.lo
Rocky Burt wrote:
> On Mon, 2007-08-01 at 15:40 +0100, Philipp von Weitershausen wrote:
>> Since Five is feature-frozen and new stuff should be added in Python
>> packages anyway, my suggestion is to put this thing into a
>> five.localsitemanager package which would then be used by CMF 2.1, Plone
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 15 Jan 2007, at 17:00, Rocky Burt wrote:
On Mon, 2007-08-01 at 15:40 +0100, Philipp von Weitershausen wrote:
Since Five is feature-frozen and new stuff should be added in Python
packages anyway, my suggestion is to put this thing into a
five.lo
On Mon, 2007-08-01 at 15:40 +0100, Philipp von Weitershausen wrote:
> Since Five is feature-frozen and new stuff should be added in Python
> packages anyway, my suggestion is to put this thing into a
> five.localsitemanager package which would then be used by CMF 2.1, Plone
> 3, etc.. It could p
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
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 ma
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martin Aspeli wrote:
> 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 utilit
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 reaso
Martin Aspeli wrote at 2007-1-8 21:35 +:
> ...
>No, no need, but I'd argue good reasons.
>
> - It's an explicit declaration of support
As is the definition of "__of__".
> - It's a lot less magic
I do not follow you:
Where is the magic with "if hasattr(local_utilitiy, '__of__')"
compar
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 8 Jan 2007, at 23:54, Martin Aspeli wrote:
Philipp von Weitershausen wrote:
a) somehow bundle CMF 2.1 (and Plone 3) with a package called
five.localsitemanager. Given that Plone 3 already has plone.*
packages (and I assume they also want fi
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 __of__(
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 __of__() in an interface some
Philipp von Weitershausen wrote:
a) somehow bundle CMF 2.1 (and Plone 3) with a package called
five.localsitemanager. Given that Plone 3 already has plone.* packages
(and I assume they also want five.customerize), this might probably be
less of an issue for Plone than for the CMF.
This is no
Martin Aspeli wrote:
Dieter Maurer wrote:
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(loc
Philipp von Weitershausen wrote:
Jens Vagelpohl wrote:
CMF won't come eggified for this release, that work has stalled.
whit wrote:
plone's egg story looks non-existent until next release.
Right, I figued as much. Also, it's only for Zope 2.11 that we can
actually tackle sensible egg suppo
Jens Vagelpohl wrote:
CMF won't come eggified for this release, that work has stalled.
whit wrote:
plone's egg story looks non-existent until next release.
Right, I figued as much. Also, it's only for Zope 2.11 that we can
actually tackle sensible egg support in the Zope 2 core, so that mak
Dieter Maurer wrote:
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
plone's egg story looks non-existent until next release.
-w
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests
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 =
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 tha
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 8 Jan 2007, at 19:40, Philipp von Weitershausen wrote:
Me neither. I'd just like to avoid that either CMF or Plone or both
grow their own implementations. The problem is completely generic
to Zope 2, hence we should have an independent package
On 8 Jan 2007, at 17:30 , Rocky Burt wrote:
On Mon, 2007-08-01 at 15:40 +0100, Philipp von Weitershausen wrote:
Using PersistentComponents() as the component registry (a.k.a. site
manager) for local sites isn't enough. That's because it doesn't
understand about containment hierarchies. Imagine 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
While I don't have time at this very moment to address this in great
detail, I will mention a few comments.
On Mon, 2007-08-01 at 15:40 +0100, Philipp von Weitershausen wrote:
> Using PersistentComponents() as the component registry (a.k.a. site
> manager) for local sites isn't enough. That's be
-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 som
-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
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
Jens Vagelpohl wrote:
-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 l
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
-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
per
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 _workable
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
>> no
-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 a
Charlie Clark wrote:
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: "
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 where we're not really af
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 re
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
a
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
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 th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 7 Jan 2007, at 14:26, Martin Aspeli wrote:
I'm getting a bit annoyed that things already decided back in
September are now being questioned. Please go back and read the
thread "Tools as local utilities", which you started,
coincidentally.
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
-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
premature? I don't th
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 acquisit
Hanno Schlichting wrote:
This is used in getToolByName first and only if the name is not
registered it falls back to the old Acquisition-based approach.
Then do we even need getToolByInterfaceName()?
I guess we do if we want this to be open-ended; essentially, if
getToolByInterfaceName() doe
Philipp von Weitershausen wrote:
> On 6 Jan 2007, at 23:22 , Martin Aspeli wrote:
>
> Actually, why dont you keep a simple mapping between existing names and
> interfaces, e.g.:
>
> name2iface = {'portal_catalog': ICatalog,
> 'portal_skins': ISkinTool,
> ...}
>
> and u
On 6 Jan 2007, at 23:22 , Martin Aspeli wrote:
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
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:
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 accepta
Hi Jens,
getToolByName on the branch will give you a DeprecationWarning.
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 premature? I don't think we can get
rid o
Jens Vagelpohl wrote:
>
> Now, the main issue is still there, how to deal with tool wrapping when
> calling getUtility/queryUtility in trusted code. Doing it every time
> right after the call is stupid. I like Tres' hardline assertion that we
> must have it wrapped every time, automatically. This
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 acquisition interming
-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
Martin Aspeli wrote:
> Hanno Schlichting wrote:
>
>> Yep, you are wrong ;)
>
> Fair enough. Out of curiosity, does the object have a __parent__?
Nope, not ILocation aware :(
> In any case, I think your original suggestion is a good one. Let's take
> this opportunity to diagnose the problem and
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
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 mu
Tres Seaver wrote:
> 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 here
>
> Fuggedd
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 u
Jens Vagelpohl wrote:
getToolByName does explicitly wrap, even when using getUtility under the
covers where it can. I don't forsee any compatibility problems there.
Cool, thanks for clearing that up.
The portal as utility is a good idea, I like it. This could be used in
many places where a t
-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.
>
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 here
> Thinking about it a bit more, I would say, that if you nee
-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
Jens Vagelpohl wrote:
>
> 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 getUtility/queryUtility, I
Jens Vagelpohl wrote:
It's just a bit unintuitive that sometimes you must wrap them, sometimes
you don't need to. For a third party coder this could turn into a major
headache and bug bear.
I would say it's very bad if we need to train people on when aq-wrapping
tools (using __of__() say) is
-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 getUtility/
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 merg
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 15 Sep 2006, at 10:16, Wichert Akkerman wrote:
Previously Jens Vagelpohl wrote:
I think the remaining question to all other stockholders (CMF
developers, CPS developers) is whether it's OK to push some of the
roadmap items out to 2.2. If that's
Previously Jens Vagelpohl wrote:
> I think the remaining question to all other stockholders (CMF
> developers, CPS developers) is whether it's OK to push some of the
> roadmap items out to 2.2. If that's OK then 2.1 doesn't have much
> left to do for it.
Depending on your release process you
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11 Sep 2006, at 11:48, Philipp von Weitershausen wrote:
You guys should probably not take this as a show stopper for CMF
2.1. I'm not at all into CMF development, but it seems most of the
items from the roadmap have indeed not been completed.
Jens Vagelpohl wrote:
Jens mentioned that there still is a fair amount of outstanding work for
2.1; I'm hoping to be able to still use an alpha release with the
current featureset.
I was under the impression there were a few "show-stoppers" that needed
CMF 2.1 (and in some cases Five) support
Hi.
Jens Vagelpohl wrote:
>
> I was under the impression there were a few "show-stoppers" that needed
> CMF 2.1 (and in some cases Five) support that weren't there yet, like
> the "customize a skin item". Are there any items you know are missing?
> You seem to apply you have everything you need.
Jens Vagelpohl wrote:
I just looked over the CMF roadmap document since we're supposed to have
a 2.1 beta in a matter of weeks and now I'm wondering if this is
possible/desirable right now:
http://www.zope.org/Products/CMF/docs/roadmap
First of all, some of the work items on the list are half
Hi!
Jens Vagelpohl wrote:
I just looked over the CMF roadmap document since we're supposed to have
a 2.1 beta in a matter of weeks and now I'm wondering if this is
possible/desirable right now:
http://www.zope.org/Products/CMF/docs/roadmap
First of all, some of the work items on the list ar
Hi Jens, all!
For the uninitiated I'm the poor guy that signed up to work on getting
Plone trunk (aka 3.0) to work with current CMF trunk (aka 2.1) amongst
other things ;)
According to the roadmap for the next Plone release we currently aim for
Plone 3.0-final to be released in January 2007. More
73 matches
Mail list logo
