Re: [Zope-CMF] Re: [CMF 2.1] FSPageTemplate & Unicode
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 __of__() for some other reason. Theoretically, you might be right -- but not practically in the "ExtensionClass" based environment of Zope 2. There you have: if an object has an "__of__" it is used for context wrapping -- as soon at it happens to be accessed as attribute of an "ExtensionClass" instance. In this environment, it is more homogenous and natural to just wrap with "__of__" when it is present than looking for an additional marker interface. > ... >I doubt it matters in this case (I'd guess __of__() is not a very common >method name outside Zope, and this would be pretty localised code)... More precisely, "__of__" has special (documented) meaning for "ExtensionClass". > >>> - It may not be desirable to wrap everything that *could* be wrapped. > ... >What if the method wasn't __of__() but get_size() or something in a >different context? I think, I would not have argued about automatic "get_size" wrapping -- unless it were so common as "ExtensionClass"'s "__of__" wrapping. -- Dieter ___ 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
[Zope-CMF] Re: [CMF 2.1] FSPageTemplate & Unicode
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 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
[Zope-CMF] Re: [CMF 2.1] FSPageTemplate & Unicode
-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 utility (to override a global one, > say) that could have __of__() for some other reason. That would be an "empty set": '__of__' is a slot which only Zope's ExtensionClasses define; it isn't used by "non-Zope python objects". > IAcquirer is an explicit, formalised statement of support for some > particular behaviour. It is a latecomer to the game, and doesn't seem "superior" to a "duck typing" check, at least to me. > I doubt it matters in this case (I'd guess __of__() is not a very common > method name outside Zope, and this would be pretty localised code), but > in general, having code be conditional on hasattr() something can lead > to spaghetti code and unintended side effects. Checking for an '__of__' on an about-to-be-returned attribute is *exactly* what ExtensionClass already does inside an attribute access; I'd say let's follow suit, rather than invent an otherwise-irrelevant contract. Or, to paraphrase the Beatles: "All you need is __of__ ... DAH dah, dadda dum... __of__ is all you need." Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFpAgn+gerLs4ltQ4RAhyeAJ9vdnZ+QGCl2tYkuNr2YHwGirFCPACgtx/k t78I+hbABDDajG0a6C5dHqY= =lTvK -END PGP SIGNATURE- ___ 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
[Zope-CMF] Re: [CMF 2.1] FSPageTemplate & Unicode
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 reason. IAcquirer is an explicit, formalised statement of support for some particular behaviour. I doubt it matters in this case (I'd guess __of__() is not a very common method name outside Zope, and this would be pretty localised code), but in general, having code be conditional on hasattr() something can lead to spaghetti code and unintended side effects. - It may not be desirable to wrap everything that *could* be wrapped. Could you explain? In the Zope 2 world, non acquisition wrapped objects behave very strange (as indicated in an earlier message). Do you want to introduce special cases only that you can use Zope 3 magic? It's pretty pointless to argue aesthetics, but I wanted to point out what was the more accepted Zope 3 pattern (in my understanding and opinion), i.e. relying on a formalised definition of some behaviour rather than the implication that if something has a particular method it must be what you think it is and must want a particular type of behaviour. What if the method wasn't __of__() but get_size() or something in a different context? Also, I think it's perfectly reasonable that some local utilities, even in a Zope 2 context, will not be acquisition wrapped. They may just be local overrides of global ones, for instance, or local utilities to gain persistence, but not for any other reason. Of course, if you want things to behave in a Zope 2 like way (containment by acquisition, security by acquisition, role manager behaviour, whatever else) then you also want to aq wrapped in a Zope 2 like way. Martin ___ 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
Re: [Zope-CMF] Re: [CMF 2.1] FSPageTemplate & Unicode
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__')" compared to "if ICMFTool.providedBy(local_utilitiy)". I feel the "ICMFTool" marker interface (almost like all marker interfaces) as more magic. > - It's prettier than getattr/hasattr Your notion of "pretty" is very much different from mine... > - If something else has an __of__() for whatever reason, we don't >catch it by accident. If "local_utilitiy" has an "__of__", then it almost surely expects that it is used in the standard way -- whether or not some magic marker interface is there > - It may not be desirable to wrap everything that *could* be wrapped. Could you explain? In the Zope 2 world, non acquisition wrapped objects behave very strange (as indicated in an earlier message). Do you want to introduce special cases only that you can use Zope 3 magic? -- Dieter ___ 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
[Zope-CMF] Re: [CMF 2.1] FSPageTemplate & Unicode
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__() in an interface somewhere? I would prefer using that (if it's promised by some mixin deep in zope anyway). Not that it greatly matters, if we actually want a policy that wraps every time. If we want wrapping to be controllable and optional, I think we need a marker interface. Fair enough, __of__() is documented by Acquisition.interfaces.IAcquirer which is provided by all objects inheriting from Aquisition.Explicit or .Implicit. That's your marker interface. -- http://worldcookery.com -- Professional Zope documentation and training 2nd edition of Web Component Development with Zope 3 is now shipping! ___ 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
[Zope-CMF] Re: [CMF 2.1] FSPageTemplate & Unicode
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 somewhere? I would prefer using that (if it's promised by some mixin deep in zope anyway). Not that it greatly matters, if we actually want a policy that wraps every time. If we want wrapping to be controllable and optional, I think we need a marker interface. Martin ___ 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
[Zope-CMF] Re: [CMF 2.1] FSPageTemplate & Unicode
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(local_utility): local_utility = local_utility.__of__(context) or so. No need to invent a new marker interface for this. Objects ready to participate in context wrapping indicate this by the "__of__" method... No, no need, but I'd argue good reasons. - It's an explicit declaration of support - It's a lot less magic - It's prettier than getattr/hasattr - If something else has an __of__() for whatever reason, we don't catch it by accident. - It may not be desirable to wrap everything that *could* be wrapped. 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. Once we support __parent__ pointers, we can phase out the wrapping. We can do that by making less and less objects have those __of__() methods for example. -- http://worldcookery.com -- Professional Zope documentation and training 2nd edition of Web Component Development with Zope 3 is now shipping! ___ 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
[Zope-CMF] Re: [CMF 2.1] FSPageTemplate & Unicode
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_utility = local_utility.__of__(context) or so. No need to invent a new marker interface for this. Objects ready to participate in context wrapping indicate this by the "__of__" method... No, no need, but I'd argue good reasons. - It's an explicit declaration of support - It's a lot less magic - It's prettier than getattr/hasattr - If something else has an __of__() for whatever reason, we don't catch it by accident. - It may not be desirable to wrap everything that *could* be wrapped. Martin ___ 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
Re: [Zope-CMF] Re: [CMF 2.1] FSPageTemplate & Unicode
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 = local_utility.__of__(context) > >or so. No need to invent a new marker interface for this. Objects ready to participate in context wrapping indicate this by the "__of__" method... -- Dieter ___ 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
Re: [Zope-CMF] Re: [CMF 2.1] FSPageTemplate & Unicode
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 registered as tools? Why? When an object implements "__of__", this indicates that it is willing to play with the "ExtensionClass" context feature (usually used for acquisition). Why can we not use this indication? -- Dieter ___ 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
[Zope-CMF] Re: [CMF 2.1] FSPageTemplate & Unicode
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 some tools don't need Acquisition to work properly. If I'm not mistaken this should let us remove all the manual AQ- wrapping again (sorry Jens for the premature patch) and thus impose no extra pain on add-on developers. The manual wrapping can be removed if we do use the special component registry which would do it for us, right. Having it done behind the scenes is obviously much better then trying to figure out if it's needed and then doing it manually. It's also the exact same behavior people got from getToolByName, so it's not really unexpected. Even in Zope3, I think that "local" utilities may need to be local, meaning that they know the "place" in which they are registered. No they don't. There's nothing implied for local utilities, not even persistence. Of course, many local utilities *are* persistent and stored in a folder somewhere, thus have a __parent__ and all that. But that's typically less of interest when *using* the utility. In Zope2, we *must* wrap them for the sake of security, if nothing else. Sadly yes. -- http://worldcookery.com -- Professional Zope documentation and training 2nd edition of Web Component Development with Zope 3 is now shipping! ___ 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
[Zope-CMF] Re: [CMF 2.1] FSPageTemplate & Unicode
-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 need Acquisition to work properly. >>> >>> If I'm not mistaken this should let us remove all the manual AQ- >>> wrapping >>> again (sorry Jens for the premature patch) and thus impose no extra >>> pain >>> on add-on developers. > > The manual wrapping can be removed if we do use the special component > registry which would do it for us, right. Having it done behind the > scenes is obviously much better then trying to figure out if it's > needed and then doing it manually. It's also the exact same behavior > people got from getToolByName, so it's not really unexpected. Even in Zope3, I think that "local" utilities may need to be local, meaning that they know the "place" in which they are registered. In Zope2, we *must* wrap them for the sake of security, if nothing else. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFombj+gerLs4ltQ4RAoQAAJ0TIjargP59yIXdW+59yEedPQwU7gCghQKv 4CichHH+qhX7WGGsdQlwukQ= =5nIX -END PGP SIGNATURE- ___ 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
Re: [Zope-CMF] Re: [CMF 2.1] FSPageTemplate & Unicode
-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 properly. If I'm not mistaken this should let us remove all the manual AQ- wrapping again (sorry Jens for the premature patch) and thus impose no extra pain on add-on developers. The manual wrapping can be removed if we do use the special component registry which would do it for us, right. Having it done behind the scenes is obviously much better then trying to figure out if it's needed and then doing it manually. It's also the exact same behavior people got from getToolByName, so it's not really unexpected. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iD8DBQFFogZBRAx5nvEhZLIRAnERAJ9k2YBajLS6iXR1oqrwU2otCovtPgCfStLc xn/i6HUcdwEX4TOzAAlhiMQ= =n/bY -END PGP SIGNATURE- ___ 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
[Zope-CMF] Re: [CMF 2.1] FSPageTemplate & Unicode
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 concerned that this >> registry is being abused a little - it really was only meant for >> getToolByName to construct a more meaningful deprecation message >> where the interface name is displayed, looked up from the tool ID. It >> seems Hanno's suggestion forces it to be kept around even after >> getToolByName has gone away in the distant future. > > 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 = local_utility.__of__(context) > > or so. We could mix ICMFTool into the interface hierarchy for CMF's > tools, or declare it explicitly on each interface. We could even be more > specific, and call it IAcquisitionDependentTool and only use it where aq > is truly needed. That's of course a better idea. I would prefer the more general name IAcquisitionDependentUtility, as it might be used by code that's not a tool in the first place. There's nothing tool specific about the interface or its usage. All that the interface should promise is that the object providing it, can be AQ-wrapped. 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 properly. If I'm not mistaken this should let us remove all the manual AQ-wrapping again (sorry Jens for the premature patch) and thus impose no extra pain on add-on developers. I'm starting to like this idea ;) Hanno ___ 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
[Zope-CMF] Re: [CMF 2.1] FSPageTemplate & Unicode
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 longer deprecation periods than others, and getToolByName() is used in pretty much every third party product (certainly every one I've written). If that is your main concern then let me put it to rest right now. getToolByName is very central, we all know that. It won't just be ripped out without some kind of consultation. I just want to scare people enough so they switch their code sooner rather than later. :) 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 concerned that this registry is being abused a little - it really was only meant for getToolByName to construct a more meaningful deprecation message where the interface name is displayed, looked up from the tool ID. It seems Hanno's suggestion forces it to be kept around even after getToolByName has gone away in the distant future. 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 = local_utility.__of__(context) or so. We could mix ICMFTool into the interface hierarchy for CMF's tools, or declare it explicitly on each interface. We could even be more specific, and call it IAcquisitionDependentTool and only use it where aq is truly needed. Martin ___ 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
[Zope-CMF] Re: [CMF 2.1] FSPageTemplate & Unicode
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 called registerToolInterface that registers a tools name and the interface that tool implements in a global registry (a simple module level dict). The primary purpose is to let getToolByName look up known tools by interface instead of using Acquisition. Nice. While I'm not too proud of my persistent component registry proposed earlier in this thread it could be extended easily to only return those utilities back AQ-wrapped that are registered in the global tools registry. See my attached aq-components.py file for a sample implementation. Personally I think AQ-wrapping every utility is a bit too much as well. I've written a number of new utilities for Plone 3.0 that while having some persistent configuration don't need any Acquisition context. Magically wrapping those might indeed lead to unexpected behavior. That is my worry too. Worse, if people start *depending* on that aq wrapping, we are going two steps forward and one step back. :) Martin ___ 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
Re: [Zope-CMF] Re: [CMF 2.1] FSPageTemplate & Unicode
-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 periods than others, and getToolByName() is used in pretty much every third party product (certainly every one I've written). If that is your main concern then let me put it to rest right now. getToolByName is very central, we all know that. It won't just be ripped out without some kind of consultation. I just want to scare people enough so they switch their code sooner rather than later. 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 concerned that this registry is being abused a little - it really was only meant for getToolByName to construct a more meaningful deprecation message where the interface name is displayed, looked up from the tool ID. It seems Hanno's suggestion forces it to be kept around even after getToolByName has gone away in the distant future. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iD8DBQFFoXozRAx5nvEhZLIRAvh5AKCPqGu6L7JJ4SPFU2c0gRf8TupvyACdFUNv 6vBg8i9OgPYnPX3Fs5Rb2V4= =bC2h -END PGP SIGNATURE- ___ 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
[Zope-CMF] Re: [CMF 2.1] FSPageTemplate & Unicode
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_ deprecation policy with accepted ways to signal deprecation and accepted deprecation periods, I'm against creating special precedents for no other reason other than to give anyone, be it Plone users or third party coders or anyone else, a _false_ sense of security. We do have precedent in Zope 3 as well as Plone where deprecation periods were extended because the breakage was unrealistic. 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 periods than others, and getToolByName() is used in pretty much every third party product (certainly every one I've written). The task isn't rocket science, it's just dull work. I know that because I've spent a long time doing it on that branch. Besides, a deprecation warning will only show up once for every specific call if I remember correctly. That's good - I was going to suggest something like that. :) Keep in mind that the only tools which will cause the DeprecationWarning to show are those defined in the CMF package. No third-party "portal_foobar" tool would cause it. Right. If you consider the relatively glacial speed of CMF releases you'll see there's nothing "quick" when the normal policy of removal two releases down the line is applied. The earliest time getToolByName could possible go away would be 2.3, and I strongly doubt it will happen then. We will warn people that it *might* happen, though. Cool. I do appreciate your desire to be conservative, but it's a bit hard to understand when I hear so many voices from the upper echelon of Plone developers wanting to completely revamp (for very good reasons) large parts of it. I completely agree that this is the right direction and I will certainly want to use this in my own code and promote it as widely as possible. I guess I'm a bit wary by some of the experience from Zope 3 (or Zope 2) where for a time the desire to "tidy" got a bit strong and things were removed because the policy said so, but which caused a lot of breakage that wasn't really necessary. So long as tools remain and remain in content space, getToolByName() can continue to exist and work (and warn, I guess); it's only a couple of lines of code, even. The deprecation serves a purpose in terms of allowing better local overrides and allowing us to eventually move the tools out of content space. It also helps avoid a dependency on CMFCore where products were only importing getToolByName() to use tools. I would argue that removing it wouldn't be better than keeping it in (with a warning), practically speaking, until tools are removed from content space, say. Once again, I think we agree on direction, perhaps disagreeing on speed. Martin ___ 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
[Zope-CMF] Re: [CMF 2.1] FSPageTemplate & Unicode
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 where we're not really after an adapter, view. > > But the returned object is almost worthless, if it is not > acquistion wrapped (otherwise, it is not even able to determine its > 'getPhysicalPath' or 'absolute_url'). > > 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 registered as tools? Jens added a new function to CMFCore.utils called registerToolInterface that registers a tools name and the interface that tool implements in a global registry (a simple module level dict). The primary purpose is to let getToolByName look up known tools by interface instead of using Acquisition. While I'm not too proud of my persistent component registry proposed earlier in this thread it could be extended easily to only return those utilities back AQ-wrapped that are registered in the global tools registry. See my attached aq-components.py file for a sample implementation. Personally I think AQ-wrapping every utility is a bit too much as well. I've written a number of new utilities for Plone 3.0 that while having some persistent configuration don't need any Acquisition context. Magically wrapping those might indeed lead to unexpected behavior. Hanno from zope.component.persistentregistry import PersistentComponents from Acquisition import aq_parent, Explicit from Products.CMFCore.utils import _tool_interface_registry class Zope2PersistentComponents(Explicit, PersistentComponents): def queryUtility(self, provided, name=u'', default=None): utilities = super(Zope2PersistentComponents, self).queryUtility(provided, name=name, default=default) if utilities is not None: # Only wrap those utilities that are also cmf tools if provided in _tool_interface_registry.values() and \ getattr(utilities, '__of__', None) is not None: return utilities.__of__(aq_parent(self)) return utilities def getUtility(self, provided, name=u''): utility = super(Zope2PersistentComponents, self).getUtility(provided, name=name) # Only wrap those utilities that are also cmf tools if provided in _tool_interface_registry.values() and \ getattr(utility, '__of__', None) is not None: return utility.__of__(aq_parent(self)) return utility ___ 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
Re: [Zope-CMF] Re: [CMF 2.1] FSPageTemplate & Unicode
-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 version or two? 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_ deprecation policy with accepted ways to signal deprecation and accepted deprecation periods, I'm against creating special precedents for no other reason other than to give anyone, be it Plone users or third party coders or anyone else, a _false_ sense of security. Changing every use of getToolByName() in every product out there (especially Plone's third party products, of which there are hundreds) is an enormous (and fairly daunting) task. If every request gets four or five of those messages, it will be counter- productive, swamping the logs. The task isn't rocket science, it's just dull work. I know that because I've spent a long time doing it on that branch. Besides, a deprecation warning will only show up once for every specific call if I remember correctly. Keep in mind that the only tools which will cause the DeprecationWarning to show are those defined in the CMF package. No third-party "portal_foobar" tool would cause it. Similarly, if we did remove it too soon, the breakage would be enormous. Probably so much so that Plone would need to monkey patch it back. I completely agree that the "new way" is better. I just think we need to be pragmatic about how strongly we warn that there is a new way, and how quickly we remove the old way. If you consider the relatively glacial speed of CMF releases you'll see there's nothing "quick" when the normal policy of removal two releases down the line is applied. The earliest time getToolByName could possible go away would be 2.3, and I strongly doubt it will happen then. We will warn people that it *might* happen, though. I do appreciate your desire to be conservative, but it's a bit hard to understand when I hear so many voices from the upper echelon of Plone developers wanting to completely revamp (for very good reasons) large parts of it. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iD8DBQFFoXUcRAx5nvEhZLIRAuicAJ42Ixm3tifMGe2cCAzeNLiPEIFxHQCgunIH ayvBbSZy9sDCr3exetZLxSg= =TmWQ -END PGP SIGNATURE- ___ 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
[Zope-CMF] Re: [CMF 2.1] FSPageTemplate & Unicode
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: "explicit is better than implicit". I agree with Jens that should go through the archive discussions on this which covered compatability issue. Anyway third party developers should be aware of and checking for the version for their dependencies (I'd like a utility for this for CMF but that's another issue) so that Product X can be categorised as working with CMF versions 1.6 and 2.0 but perhaps not 2.1. +1 to go ahead with Jens' branch. 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 version or two? Changing every use of getToolByName() in every product out there (especially Plone's third party products, of which there are hundreds) is an enormous (and fairly daunting) task. If every request gets four or five of those messages, it will be counter-productive, swamping the logs. Similarly, if we did remove it too soon, the breakage would be enormous. Probably so much so that Plone would need to monkey patch it back. I completely agree that the "new way" is better. I just think we need to be pragmatic about how strongly we warn that there is a new way, and how quickly we remove the old way. Martin ___ 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
Re: [Zope-CMF] Re: [CMF 2.1] FSPageTemplate & Unicode
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 after an adapter, view. But the returned object is almost worthless, if it is not acquistion wrapped (otherwise, it is not even able to determine its 'getPhysicalPath' or 'absolute_url'). Thus, the proposal exhibits an essential example that local utilities should be returned acquisition wrapped (if the have an '__of__' method). -- Dieter ___ 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
Re: [Zope-CMF] Re: [CMF 2.1] FSPageTemplate & Unicode
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 wouldn't be wrapped. I >> think this might be an acceptable trade-off. > >Are you sure? Does *every* local utility want an aq wrapper? Some of them want (e.g. the "Catalog" and the proposed "ISiteRoot" "utilitiy"). Thus, it is easier (for all of us) when all utilities with an "__of__" method are wrapped. > >I'm not even sure if tools that are well-written (do not rely on >acquiring things from 'self') need to do so except for security when >called TTW, in which case getToolBy(Interface)Name will do the trick. > >Bluntly adding acquisition like this seems like a step in the wrong >direction, imho. Currently returned tools (via "getToolByName") are acquisition wrapped. I think this should stay this way. In Zope 2, non acquisition wrapped objects behave very strangely. E.g. most "OFS.Traversable.Traversable" methods no longer work correctly; and (as you already noted) security fails. In my view, this indicates that all objects with "__of__" method should be correctly acquisition wrapped. -- Dieter ___ 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
[Zope-CMF] Re: [CMF 2.1] FSPageTemplate & Unicode
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 against the current CMFCore branch, that in combination with the small change to DCWorkflow/Expressions.py noted earlier is needed to get most of the tests for Plone running. I still have one problem in the test case setup for functional tests, where the portal isn't set as a site and thus the utility lookups don't work, but as far as I can tell this is only a test case problem. Hanno Index: MembershipTool.py === --- MembershipTool.py (revision 71776) +++ MembershipTool.py (working copy) @@ -503,6 +503,7 @@ # Delete member data in portal_memberdata. mdtool = queryUtility(IMemberDataTool) if mdtool is not None: +mdtool = mdtool.__of__(self) for member_id in member_ids: mdtool.deleteMemberData(member_id) @@ -513,7 +514,7 @@ # Delete members' local roles. if delete_localroles: -utool = getUtility(IURLTool) +utool = getUtility(IURLTool).__of__(self) self.deleteLocalRoles( utool.getPortalObject(), member_ids, reindex=1, recursive=1 ) Index: MemberDataTool.py === --- MemberDataTool.py (revision 71776) +++ MemberDataTool.py (working copy) @@ -184,7 +184,7 @@ def pruneMemberDataContents(self): """ Delete data contents of all members not listet in acl_users. """ -membertool= getUtility(IMembershipTool) +membertool= getUtility(IMembershipTool).__of__(self) members = self._members user_list = membertool.listMemberIds() Index: RegistrationTool.py === --- RegistrationTool.py (revision 71776) +++ RegistrationTool.py (working copy) @@ -159,7 +159,7 @@ # Anyone is always allowed to grant the 'Member' role. _limitGrantedRoles(roles, self, ('Member',)) -membership = getUtility(IMembershipTool) +membership = getUtility(IMembershipTool).__of__(self) membership.addMember(id, password, roles, domains, properties) member = membership.getMemberById(id) Index: URLTool.py === --- URLTool.py (revision 71776) +++ URLTool.py (working copy) @@ -24,6 +24,7 @@ from zope.interface import implements from ActionProviderBase import ActionProviderBase +from interfaces import ISiteRoot from interfaces import IURLTool from interfaces.portal_url import portal_url as z2IURLTool from permissions import ManagePortal @@ -74,7 +75,15 @@ def getPortalObject(self): """ Get the portal object itself. """ -return aq_parent( aq_inner(self) ) +portal = aq_inner(self) +while True: +portal = getattr(portal, 'aq_parent', None) +if portal is None: +break +if ISiteRoot.providedBy(portal): +return portal +# Portal could not be found, log an error or raise one? +return aq_inner(self) security.declarePublic('getRelativeContentPath') def getRelativeContentPath(self, content): Index: ActionInformation.py === --- ActionInformation.py(revision 71776) +++ ActionInformation.py(working copy) @@ -504,7 +504,7 @@ def __init__( self, tool, folder, object=None ): self.portal = portal = aq_parent(aq_inner(tool)) -membership = getUtility(IMembershipTool) +membership = getUtility(IMembershipTool).__of__(portal) self.isAnonymous = membership.isAnonymousUser() self.user_id = membership.getAuthenticatedMember().getId() self.portal_url = portal.absolute_url() Index: PortalFolder.py === --- PortalFolder.py (revision 71776) +++ PortalFolder.py (working copy) @@ -125,7 +125,7 @@ this folder. """ result = [] -portal_types = getUtility(ITypesTool) +portal_types = getUtility(ITypesTool).__of__(self) myType = portal_types.getTypeInfo(self) if myType is not None: Index: CMFCatalogAware.py === --- CMFCatalogAware.py (revision 71776) +++ CMFCatalogAware.py (working copy) @@ -118,6 +118,7 @@ if catalog is None: return path = '/'.join(self.getPhysicalPath()) +catalog = catalog.__of__(self) # XXX if _getCatalogTool() is overriden w
[Zope-CMF] Re: [CMF 2.1] FSPageTemplate & Unicode
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). > > The thread I pointed out clearly spells out the deprecation and the > DeprecationWarning. I'm somewhat surprised how DeprecationWarnings are > an issue. Clearly, in the past the Plone developer community hasn't been > too concerned about DeprecationWarning messages. I'm fine with deprecating getToolByName. This will spit out tons of deprecation warnings but those can be fixed (and I know I'm probably going to be the one doing most of that work for Plone core ;)) As a side note, I tried to bring Plone 3.0 into a state where it doesn't spit out deprecation warnings anymore and while I haven't been completely successful it has gotten a lot better than it used to be. >> 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? > > I don't agree. I vote for keeping it in. There is no other obvious way > to alert developers of this change. Besides, that's _the_ way > deprecations have always been handled. Why should this one be different? This one is no different IMO. > Anyway, I propose the following: > > - the tool work to make them less dependent on acquisition is a good > idea, but it's out of scope for the part I volunteered for. Others are > welcome to step forward. Yep, I feared that ;) > - I'll continue with the work the way I have been doing it so far, > there's just a couple small tools left and invocations in Yvo's browser > view classes. > > - 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. OK, after all I think this approach is not that bad. My current testing of the CMF branches against Plone trunk shows only one major problem and about two minor places where we would need to adjust some code. The major problem is that the skin isn't set properly on the thread right now in the tests, so skin Acquisition magic doesn't work, which results in some hundred test failures for CMFPlone. > - *However*, I won't touch any more code until we have some consensus > here. > > Don't get me wrong, even if we come to a conclusion that spells "throw > away the branch" or "rewrite it all" I don't care, I just want some > final word and no more re-opening of discussions. Anything else is > analysis paralysis and a waste of time. OK, you get my +0.5 on moving forward. In the end this branch will bring us a big step forward towards Zope3 adaptation and all the benefits that result from it. Hanno ___ 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
Re: [Zope-CMF] Re: [CMF 2.1] FSPageTemplate & Unicode
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 than implicit". I agree with Jens that should go through the archive discussions on this which covered compatability issue. Anyway third party developers should be aware of and checking for the version for their dependencies (I'd like a utility for this for CMF but that's another issue) so that Product X can be categorised as working with CMF versions 1.6 and 2.0 but perhaps not 2.1. +1 to go ahead with Jens' branch. Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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
Re: [Zope-CMF] Re: [CMF 2.1] FSPageTemplate & Unicode
-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. I have spent days and days going down this route. This is a very large piece of work and I took it over voluntarily because everyone thought it was a good idea. I'm sorry if I caused offense; I am very, very happy that you decided this was worth your time, and I think it will be a very important stepping stone in making CMF 2.1+ better and easier to integrate with. You're not causing offense, I just feel like I'm in the typical customer situation where requirements and expectations change at the last minute. With the customer I have to grin and bear it, but for my spare time work I claim the luxury of yelling "party foul!". 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). The thread I pointed out clearly spells out the deprecation and the DeprecationWarning. I'm somewhat surprised how DeprecationWarnings are an issue. Clearly, in the past the Plone developer community hasn't been too concerned about DeprecationWarning messages. 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? I don't agree. I vote for keeping it in. There is no other obvious way to alert developers of this change. Besides, that's _the_ way deprecations have always been handled. Why should this one be different? Anyway, I propose the following: - - the tool work to make them less dependent on acquisition is a good idea, but it's out of scope for the part I volunteered for. Others are welcome to step forward. - - I'll continue with the work the way I have been doing it so far, there's just a couple small tools left and invocations in Yvo's browser view classes. - - 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. - - *However*, I won't touch any more code until we have some consensus here. Don't get me wrong, even if we come to a conclusion that spells "throw away the branch" or "rewrite it all" I don't care, I just want some final word and no more re-opening of discussions. Anything else is analysis paralysis and a waste of time. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iD8DBQFFoPpmRAx5nvEhZLIRAmyDAJ4gjFJsu8Qugx/Alaiv9yBNOoMo7gCeLk06 ay+/xnj0s2IKv5OsM01tLys= =fVAO -END PGP SIGNATURE- ___ 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
[Zope-CMF] Re: [CMF 2.1] FSPageTemplate & Unicode
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 premature? I don't think we can get rid of getToolByName() for a long time, practically, but new code should be encouraged from using the new utility based lookup. 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. I have spent days and days going down this route. This is a very large piece of work and I took it over voluntarily because everyone thought it was a good idea. I'm sorry if I caused offense; I am very, very happy that you decided this was worth your time, and I think it will be a very important stepping stone in making CMF 2.1+ better and easier to integrate with. 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). 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? Martin ___ 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
Re: [Zope-CMF] Re: [CMF 2.1] FSPageTemplate & Unicode
-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 think we can get rid of getToolByName() for a long time, practically, but new code should be encouraged from using the new utility based lookup. 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. I have spent days and days going down this route. This is a very large piece of work and I took it over voluntarily because everyone thought it was a good idea. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iD8DBQFFoMaARAx5nvEhZLIRAkjZAJ9GXyvCGElwUjuMLRrGwvn+QD10twCdGC73 HPcT+5SkCo100Z2vKzHWCeA= =CHQw -END PGP SIGNATURE- ___ 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
[Zope-CMF] Re: [CMF 2.1] FSPageTemplate & Unicode
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 acquisition intermingling. I'm not sure they'd apply here. Yep, he worked on making the Zope 2 security policy aware of the ILocation interface as an alternative to the Acquisition hierarchy IIRC. This is targeted at Zope 2.11 though and last time I asked he still got segfaults ;) I still do as I haven't found much time to work on this further. I'm looking for someone to take over my branch (knowledge of Python C API and experience with debugging C code required). I consider this a crucial step in moving forward. Acquisition is really getting in the way now and having the simpler __parent__ API be supported as an alternative in Zope 2 would simplify things a lot -- also in this case. Alas, I'm running out of time and experience with this stuff. :( -- http://worldcookery.com -- Professional Zope documentation and training 2nd edition of Web Component Development with Zope 3 is now shipping! ___ 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
[Zope-CMF] Re: [CMF 2.1] FSPageTemplate & Unicode
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() does no checks (like, target provides ICMFTool or something) then this becomes a generic get-and-aq-wrap-any-utility function. That may or may not be a good idea to have. Martin ___ 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
[Zope-CMF] Re: [CMF 2.1] FSPageTemplate & Unicode
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 use that in getToolByName? Then *all* of the existing code base > continues to work, especially if getToolByName does aq wrapping. > getToolByName('some.dotted.interface.IName') looks silly. We already have that. It's called _tool_interface_registry and can be found in CMFCore/utils.py ;) This is used in getToolByName first and only if the name is not registered it falls back to the old Acquisition-based approach. Hanno ___ 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
[Zope-CMF] Re: [CMF 2.1] FSPageTemplate & Unicode
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 for getToolBy(Interface)Name() to handle this. - Non-TTW code probably shouldn't need aq contexts. - 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 after an adapter, view. - Using component registries would be bad in terms of maintenance; in my own opinion, aq-wrapping when it may not be needed may lead to headaches later as well. Also, in my own opinion, why don't we keep getToolByName() (since it's so incredibly prevalent) and just let it handle dotted interface names as well? The chances of a name clash are minute, and we can at a later stage deprecate the non-dotted names. I say this because (a) getToolByInterfaceName() is long :) and (b) it's one more thing to remember and (c) everyone's already using getToolByName(). Actually, why dont you keep a simple mapping between existing names and interfaces, e.g.: name2iface = {'portal_catalog': ICatalog, 'portal_skins': ISkinTool, ...} and use that in getToolByName? Then *all* of the existing code base continues to work, especially if getToolByName does aq wrapping. getToolByName('some.dotted.interface.IName') looks silly. ___ 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
[Zope-CMF] Re: [CMF 2.1] FSPageTemplate & Unicode
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. - Non-TTW code probably shouldn't need aq contexts. - 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 after an adapter, view. - Using component registries would be bad in terms of maintenance; in my own opinion, aq-wrapping when it may not be needed may lead to headaches later as well. Also, in my own opinion, why don't we keep getToolByName() (since it's so incredibly prevalent) and just let it handle dotted interface names as well? The chances of a name clash are minute, and we can at a later stage deprecate the non-dotted names. I say this because (a) getToolByInterfaceName() is long :) and (b) it's one more thing to remember and (c) everyone's already using getToolByName(). Martin ___ 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
[Zope-CMF] Re: [CMF 2.1] FSPageTemplate & Unicode
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 acceptable trade-off. Are you sure? Does *every* local utility want an aq wrapper? I'm not even sure if tools that are well-written (do not rely on acquiring things from 'self') need to do so except for security when called TTW, in which case getToolBy(Interface)Name will do the trick. Bluntly adding acquisition like this seems like a step in the wrong direction, imho. If we *know* that *every* local utility needs this, then it's a pretty elegant solution. I would like some assurances from Tres, Philipp or others for that, though. Martin ___ 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
[Zope-CMF] Re: [CMF 2.1] FSPageTemplate & Unicode
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 of getToolByName() for a long time, practically, but new code should be encouraged from using the new utility based lookup. Before that happens, though, this needs to work 100% of the time, without requring client code to play aq tricks. The branch does provide an alternative to getToolByName for untrusted code that I think is close to the whole utility idea. I call it "getToolByInterfaceName" and instead of a tool ID you pass in the interface's dotted name as a string: getToolByName(context, 'portal_actions') would become getToolByInterfaceName(context, 'Products.CMFCore.interfaces.IActionsTool') whereas everything else stays the same, meaning you can pass in a default, and the method will wrap the tool before handing it back. However, instead of AttributeError, this one raises ComponentLookupError, but that decision can always be revisited. So what does this really buy us over, say, a map of tools names to interfaces? Is it (in the short/medium term) really worth spewing warning from tons and tons of code? 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 needs to be implemented somehow, maybe in Five as he suggests. I'm not quite sure I follow the argument that it must be wrapped every time. I agree that it must for TTW code (page templates, scripts), for security. For other things, we may want instead to rely on the pattern that's been mentioned: use getUtility(ISiteRoot) to get the portal root and don't rely on acquiring attributes (from self in the tool) otherwise. I may not have fully understood the implications of this, though. Martin ___ 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
[Zope-CMF] Re: [CMF 2.1] FSPageTemplate & Unicode
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 needs to be > implemented somehow, maybe in Five as he suggests. > > How do we proceed? Personally I like Tres idea as well. I had one idea so far that achieves this without monkey-patching the functions in zope.component. 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 acceptable trade-off. Instead of creating a PersistentComponents registry in setuphandlers.py in CMFDefault (or CMFPlone) we could use the following one: from zope.component.persistentregistry import PersistentComponents from Acquisition import aq_parent, Explicit class Zope2PersistentComponents(Explicit, PersistentComponents): def queryUtility(self, provided, name=u'', default=None): utilities = super(Zope2PersistentComponents, self).queryUtility(provided, name=name, default=default) if utilities is not None: if getattr(utilities, '__of__', None) is not None: return utilities.__of__(aq_parent(self)) return utilities def getUtility(self, provided, name=u''): utility = super(Zope2PersistentComponents, self).getUtility(provided, name=name) if getattr(utility, '__of__', None) is not None: return utility.__of__(aq_parent(self)) return utility I'm not sure about all the implications this has, so treat it with care ;) Also we would probably need to overwrite all the other methods that return utilities like getUtilitiesFor, registeredUtilities, ... and we would need to make a decision about how to handle adapters or subscribers. Thoughts? Hanno ___ 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
[Zope-CMF] Re: [CMF 2.1] FSPageTemplate & Unicode
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 intermingling. I'm not sure they'd > apply here. Yep, he worked on making the Zope 2 security policy aware of the ILocation interface as an alternative to the Acquisition hierarchy IIRC. This is targeted at Zope 2.11 though and last time I asked he still got segfaults ;) >> Ah yep, you are of course right. My main point was probably that it >> shouldn't rely on the request (unless passed in explicitly as a method >> argument). > > And sometimes we have methods that can legitimately take a 'context' > parameter. Quite often, this is because we were really after a view, > though. For example, most of PloneTool.py is a hodge-podge of random > things that were needed in page templates and Script (Python)'s but that > people wanted in filesystem code. That crap has to be refactored completely. The complete Plone tool has to be ripped apart and turned into nice utilities and views... Hanno ___ 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
Re: [Zope-CMF] Re: [CMF 2.1] FSPageTemplate & Unicode
-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 can do any additional security related things. In filesystem code, though, I think the security aspect won't matter in most cases. getToolByName on the branch will give you a DeprecationWarning. The branch does provide an alternative to getToolByName for untrusted code that I think is close to the whole utility idea. I call it "getToolByInterfaceName" and instead of a tool ID you pass in the interface's dotted name as a string: getToolByName(context, 'portal_actions') would become getToolByInterfaceName(context, 'Products.CMFCore.interfaces.IActionsTool') whereas everything else stays the same, meaning you can pass in a default, and the method will wrap the tool before handing it back. However, instead of AttributeError, this one raises ComponentLookupError, but that decision can always be revisited. 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 needs to be implemented somehow, maybe in Five as he suggests. How do we proceed? jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iD8DBQFFoA7bRAx5nvEhZLIRAk0IAJ9FRh3daPcHkEOZknzg0E3DkGdlYQCfQrCt zPpvOs0m2Q/mTMubvknO+Gc= =nsnx -END PGP SIGNATURE- ___ 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
[Zope-CMF] Re: [CMF 2.1] FSPageTemplate & Unicode
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 not the symptom: "True" > tools should be singletons and act much like utilities. Stuff like > self.REQUEST is pretty nasty. Maybe some tools will need some internal > cleanup in that respect; my feeling is that in most cases, that cleanup > should be reasonably easy, and where it's not perhaps we wait to put > those methods into the corresponding utility interfaces and think about > using adapters instead. The only question is who does this tool cleanup ;) > As Tres points out, you need aq context for security and in case > something is contained in the tool and needs proper containment > acquisition. portal_factory is such an example. I don't know if > portal_actions would be now as well; portal_types probably too. > > These are not really utilities, though, they are magic singleton > containers for specific things. Whereas a tool that is converted to a > utility may one day be deprecated out of content space, these ones may > not, I don't know. Hhm, ok. So do we expose these tools at utilities now at all? Can we really deprecate getToolByName then? > 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 can do any > additional security related things. In filesystem code, though, I think > the security aspect won't matter in most cases. Jens came up with a nice alternative here, which is getToolByInterfaceName. The docstrings reads: """Get a tool by its fully-qualified dotted interface path. This method replaces getToolByName for use in untrusted code. Trusted code should use zope.component.getUtility instead.""" Hanno ___ 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
[Zope-CMF] Re: [CMF 2.1] FSPageTemplate & Unicode
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 here. Personally I have no clue how Acquisition and security are intermingled in Zope 2, so cannot suggest any reasonable behavior here. Spend some time in AccessControl/ImplPython.py. :) Ah yep, you are of course right. My main point was probably that it shouldn't rely on the request (unless passed in explicitly as a method argument). And sometimes we have methods that can legitimately take a 'context' parameter. Quite often, this is because we were really after a view, though. For example, most of PloneTool.py is a hodge-podge of random things that were needed in page templates and Script (Python)'s but that people wanted in filesystem code. Martin ___ 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
[Zope-CMF] Re: [CMF 2.1] FSPageTemplate & Unicode
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 much like utilities. Stuff like self.REQUEST is pretty nasty. Maybe some tools will need some internal cleanup in that respect; my feeling is that in most cases, that cleanup should be reasonably easy, and where it's not perhaps we wait to put those methods into the corresponding utility interfaces and think about using adapters instead. As Tres points out, you need aq context for security and in case something is contained in the tool and needs proper containment acquisition. portal_factory is such an example. I don't know if portal_actions would be now as well; portal_types probably too. These are not really utilities, though, they are magic singleton containers for specific things. Whereas a tool that is converted to a utility may one day be deprecated out of content space, these ones may not, I don't know. 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 can do any additional security related things. In filesystem code, though, I think the security aspect won't matter in most cases. Martin ___ 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
[Zope-CMF] Re: [CMF 2.1] FSPageTemplate & Unicode
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 > > Fuggeddaboudit -- this is Zope2, and acquisition is still crucial (and > will remain so for the foreseeable future). Tools-qua-utilities *need* > wrapping in order for Zope2's security machinery to operate. If Five's > "local utility" bits don't arrange to wrap their own registered > utilities (not those gotten by "acquiring" from above), then we need to > change them to do so. Five doesn't do anything special for any utilities for Zope 2. It relies completely on the Zope 3 implementation, which of course doesn't know anything about Acquisition. PhiliKON some time ago suggested that Five should wrap the utilities eventually but nobody followed up on that idea. Personally I have no clue how Acquisition and security are intermingled in Zope 2, so cannot suggest any reasonable behavior here. >>> In the end a utility is defined as something that does not need a >>> context to do it's work. > > You are confusing "context" here -- the utility doesn't need to have an > "adapterish" context, but it *does* need to have "containment" context > -- that is why it is "local" in the first place. Ah yep, you are of course right. My main point was probably that it shouldn't rely on the request (unless passed in explicitly as a method argument). Hanno ___ 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
[Zope-CMF] Re: [CMF 2.1] FSPageTemplate & Unicode
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 > > especially since the errors I get will likely be confusing. I have > learned the hard way that having to understand how acquisition interacts > with your code fully can be painful, and that sometimes the Zope2/Zope3 > divide still forces this on developers. In this case, we need to make it > as hard as possible to make mistakes, or the learning curve will just > shoot up again. > > In fact, I'm not quite sure I understand the full extent of the problem > here, which is why I'm not being more pro-active in offering suggestions. > > Now, I assume we still create the tool objects as > portal['portal_membership'] or whatever, i.e. they are still > SimpleItem's or whatever, so they still have acquisition mixed in. > Presumably, they should also have an aq_parent always, no? > > Then, I assume that on portal setup, we do > registerUtility(provides=IMembershipTool, > component=portal.portal_membership) - that is, we are telling the > persistent local utility registry that we are using the same physical > object (in the ZODB), rather than giving it a factory from which to > create its own object. > > This is what leads to believe there ought to be an aq_parent by > containment, but I guess I may be wrong? Yep, you are wrong ;) A sample session from my local zopectl debug: >>> from Products.CMFPlone.interfaces import ITranslationServiceTool >>> from zope.component import getUtility >>> getUtility(ITranslationServiceTool, context=app.test) >>> getUtility(ITranslationServiceTool, context=app.test).aq_parent Traceback (most recent call last): File "", line 1, in ? AttributeError: aq_parent >>> from Products.CMFCore.utils import getToolByName >>> getToolByName(app.test, 'translation_service') >>> getToolByName(app.test, 'translation_service').aq_chain [, , ] You currently don't get any Acquisition context for utilities if you don't wrap them explicitly: >>> getUtility(ITranslationServiceTool, context=app.test).__of__(app.test).aq_chain [, , ] Hanno ___ 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
[Zope-CMF] Re: [CMF 2.1] FSPageTemplate & Unicode
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 tool itself wants to acquire something, which is usually something else at the portal root. I'm not sure about the user folder implications that you mention. The security machinery may fail if a user originates in a user folder above the portal, which cannot be reached by acquisition anymore. That would of course also be bad; people expect to be able to log in with their root admin username. 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 especially since the errors I get will likely be confusing. I have learned the hard way that having to understand how acquisition interacts with your code fully can be painful, and that sometimes the Zope2/Zope3 divide still forces this on developers. In this case, we need to make it as hard as possible to make mistakes, or the learning curve will just shoot up again. In fact, I'm not quite sure I understand the full extent of the problem here, which is why I'm not being more pro-active in offering suggestions. Now, I assume we still create the tool objects as portal['portal_membership'] or whatever, i.e. they are still SimpleItem's or whatever, so they still have acquisition mixed in. Presumably, they should also have an aq_parent always, no? Then, I assume that on portal setup, we do registerUtility(provides=IMembershipTool, component=portal.portal_membership) - that is, we are telling the persistent local utility registry that we are using the same physical object (in the ZODB), rather than giving it a factory from which to create its own object. This is what leads to believe there ought to be an aq_parent by containment, but I guess I may be wrong? Martin ___ 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
[Zope-CMF] Re: [CMF 2.1] FSPageTemplate & Unicode
-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 here Fuggeddaboudit -- this is Zope2, and acquisition is still crucial (and will remain so for the foreseeable future). Tools-qua-utilities *need* wrapping in order for Zope2's security machinery to operate. If Five's "local utility" bits don't arrange to wrap their own registered utilities (not those gotten by "acquiring" from above), then we need to change them to do so. >> Thinking about it a bit more, I would say, that if you need to aq_wrap a >> tool in order for it to function as expected, you shouldn't really >> register it as a utility in the first place. > > Maybe, maybe not. I would go as far as to say that 75% of the time when > a tool needs an acquisition context, all it really needs it for is to > get to the portal object. From there it can usually do whatever it > wants. Why not clean up the tools a bit so that instead of trying to do > something acquired, it looks up the portal and goes from there instead? > Or maybe that's biting off a bit too much? > > I recently had the problem where in certain circumstances if you're > inside the mutator or accessor of a python property, then aq is not > maintained which prevented me from doing tool lookups that I needed to > do (Plone 2.5 / CMF 1.6). What I ended up doing was calling > getToolByName(zope.app.component.hooks.getSite(), 'sometool'). Of > course if we make getUtility(ISiteRoot) work, we could use that instead > of the zope.app.component.hooks.getSite() rule. Although, I'd love to > see utility lookups from one utility to another just use ISite and note > ISiteRoot as it would make overriding tools in "sub-portals" much > easier. > > >> In the end a utility is defined as something that does not need a >> context to do it's work. You are confusing "context" here -- the utility doesn't need to have an "adapterish" context, but it *does* need to have "containment" context - -- that is why it is "local" in the first place. > Hm... I'm not convinced of this, for me using "local" utilities versus > global utilities is about being able to get to the portal somehow. > Perhaps I'm mis-using local utilities? I don't think so. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFn+/O+gerLs4ltQ4RAm26AKCFWasXbK4htOKfGsQ/N3tZAsSuPACg3KWi LmDHaqjso+cvQVKW93ImZEY= =R+be -END PGP SIGNATURE- ___ 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
[Zope-CMF] Re: [CMF 2.1] FSPageTemplate & Unicode
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 need to aq_wrap a > tool in order for it to function as expected, you shouldn't really > register it as a utility in the first place. Maybe, maybe not. I would go as far as to say that 75% of the time when a tool needs an acquisition context, all it really needs it for is to get to the portal object. From there it can usually do whatever it wants. Why not clean up the tools a bit so that instead of trying to do something acquired, it looks up the portal and goes from there instead? Or maybe that's biting off a bit too much? I recently had the problem where in certain circumstances if you're inside the mutator or accessor of a python property, then aq is not maintained which prevented me from doing tool lookups that I needed to do (Plone 2.5 / CMF 1.6). What I ended up doing was calling getToolByName(zope.app.component.hooks.getSite(), 'sometool'). Of course if we make getUtility(ISiteRoot) work, we could use that instead of the zope.app.component.hooks.getSite() rule. Although, I'd love to see utility lookups from one utility to another just use ISite and note ISiteRoot as it would make overriding tools in "sub-portals" much easier. > In the end a utility is defined as something that does not need a > context to do it's work. Hm... I'm not convinced of this, for me using "local" utilities versus global utilities is about being able to get to the portal somehow. Perhaps I'm mis-using local utilities? > Registering tools as utilities that either need > an Acquisition context or even worse the request (think of the evil > self.REQUEST you see sometimes) violates that very definition of what > utilities are. Indeed, using request inside a utility/tool is evil. But > But maybe I'm just in a bit too cautious mood right now ;) It does seem that way ;) Regards, Rocky -- Rocky Burt ServerZen Software -- http://www.serverzen.com News About The Server (blog) -- http://www.serverzen.net signature.asc Description: This is a digitally signed message part ___ 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
Re: [Zope-CMF] Re: [CMF 2.1] FSPageTemplate & Unicode
-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 of existing code. If getToolByName() keps aq wrapping, though, then legacy code shouldn't be affected, so it's only new code using getUtility(). getToolByName does explicitly wrap, even when using getUtility under the covers where it can. I don't forsee any compatibility problems there. In this case, we probably need to fix the tools themselves so that they don't depend on being aq-wrapped. Actually, Hanno's suggestion is kind of neat. Let the persistent portal object be a (the only) utility providing ISiteRoot in the local utility registry, and when tools need to get the portal, root, do: portal = getUtility(ISiteRoot) I guess it's rare that we'd want to acquire anything from above the portal in a tool (user folders being the only thing I can think of). The portal as utility is a good idea, I like it. This could be used in many places where a tool itself wants to acquire something, which is usually something else at the portal root. I'm not sure about the user folder implications that you mention. The security machinery may fail if a user originates in a user folder above the portal, which cannot be reached by acquisition anymore. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iD8DBQFFn9JfRAx5nvEhZLIRAlZNAJwJPlfjpAGoSi7/xkY4evI05hC8OACfbiiR ihQq3MU3UV0Rg5YstulPJLU= =40oN -END PGP SIGNATURE- ___ 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
[Zope-CMF] Re: [CMF 2.1] FSPageTemplate & Unicode
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 am assuming the > returned utility should always considered to be unwrapped. Because > that's what the unit tests show me. There are several places where CMF > unit tests failed and I ended up manually wrapping the utility where I > retrieved it using __of__, but I'm not sure if I'm expected to do it > that way. It's clear that some tools must be wrapped in order to perform > their function - that's why for example the method I wrote to replace > getToolByName for untrusted code still expects a context to be passed > along and I wrap the utility in it. > > 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. 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. Thinking about it a bit more, I would say, that if you need to aq_wrap a tool in order for it to function as expected, you shouldn't really register it as a utility in the first place. The forced aq_wrapping is like introducing a new required context argument in a method. You effectively change the methods signature, which shouldn't be done without a deprecation period at least. In the end a utility is defined as something that does not need a context to do it's work. Registering tools as utilities that either need an Acquisition context or even worse the request (think of the evil self.REQUEST you see sometimes) violates that very definition of what utilities are. While I would really love to see getToolByName vanish as fast as possible I'm not sure if we can do this as easily as it first looked. Maybe we could offer those tools as utilities that are real utilities for CMF 2.1 and start rewriting those tools that are really more like adapters as such, removing the tools altogether or splitting them up into utilities and adapter parts. I know this isn't a scenario that would produce major results in the near future considering the number of people that currently contribute to CMF but maybe it's the safer approach. But maybe I'm just in a bit too cautious mood right now ;) Hanno ___ 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
[Zope-CMF] Re: [CMF 2.1] FSPageTemplate & Unicode
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 required and when it's not. In fact, I'd say its catastrophic and will break incredible amounts of existing code. If getToolByName() keps aq wrapping, though, then legacy code shouldn't be affected, so it's only new code using getUtility(). In this case, we probably need to fix the tools themselves so that they don't depend on being aq-wrapped. Actually, Hanno's suggestion is kind of neat. Let the persistent portal object be a (the only) utility providing ISiteRoot in the local utility registry, and when tools need to get the portal, root, do: portal = getUtility(ISiteRoot) I guess it's rare that we'd want to acquire anything from above the portal in a tool (user folders being the only thing I can think of). We may yet find ourselves in pain in things like Remember or PlonePAS or bits of CMFPlone that override and monkey patch tools, but at least those can be contained. Martin ___ 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
Re: [Zope-CMF] Re: [CMF 2.1] FSPageTemplate & Unicode
-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/queryUtility, I am assuming the returned utility should always considered to be unwrapped. Because that's what the unit tests show me. There are several places where CMF unit tests failed and I ended up manually wrapping the utility where I retrieved it using __of__, but I'm not sure if I'm expected to do it that way. It's clear that some tools must be wrapped in order to perform their function - that's why for example the method I wrote to replace getToolByName for untrusted code still expects a context to be passed along and I wrap the utility in it. 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. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iD4DBQFFn7eYRAx5nvEhZLIRAouMAJ4rDlUqxta4tkC0IGIDzk2INNeG5wCVHi6k tGCzE5BwZhM7kJFx5pBB8Q== =t6kR -END PGP SIGNATURE- ___ 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
[Zope-CMF] Re: [CMF 2.1] FSPageTemplate & Unicode
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 without side-effects :-) Well see ;) But Plone shouldn't have too many problems with it, as it monkey-patches the hell out of the Zope3 tal and pagetemplate packages anyways, as it produces UnicodeDecodeErrors all over the place otherwise. > Now is the best time, I'm sure Plone 3 testing will give it the best > workout it can get. I hope to finish my huge checkin (deprecating > getToolByName and replacing it with utility calls) this weekend. Regarding your greatly appreciated utilities work, I have tried it with the current Plone 3 bundle and found various problems. After fixing various code snippets, I have it in a state where the tests start at least and we get about 200 errors for the CMFPlone tests. I had to change two things in CMF so far though. Here are the patches I came up with: In DCWorkflow/Expression.py the workflow is not aq-wrapped anymore, so you cannot call getPhysicalRoot on it anymore. But luckily we can use the object instead. The second one is even more important. The URLTool's getPortalObject method was pretty dumb so far and returned the aq_parent of the tool. As the tool can get pretty awkward aq_chains now, as getToolByName wraps the tool inside the callers context, we need a better approach. The simplest one I came up with is to do an recursive loop and check if the parent implements ISiteRoot. This should get you the real portal object. At least with this patch another 300 unit tests pass in CMFPlone where about 500 failed before. Another way would potentially be to register the portal object itself as a utility, so you could query it directly, but that would be a bit of an extra work... I'll try to find out what's causing the other test failures in Plone :) Hanno Index: Expression.py === --- Expression.py (revision 71731) +++ Expression.py (working copy) @@ -122,7 +122,7 @@ 'container':container, 'folder': container, 'nothing': None, -'root': wf.getPhysicalRoot(), +'root': ob.getPhysicalRoot(), 'request': getattr( ob, 'REQUEST', None ), 'modules': SecureModuleImporter, 'user': getSecurityManager().getUser(), Index: URLTool.py === --- URLTool.py (revision 71731) +++ URLTool.py (working copy) @@ -24,6 +24,7 @@ from zope.interface import implements from ActionProviderBase import ActionProviderBase +from interfaces import ISiteRoot from interfaces import IURLTool from interfaces.portal_url import portal_url as z2IURLTool from permissions import ManagePortal @@ -74,7 +75,15 @@ def getPortalObject(self): """ Get the portal object itself. """ -return aq_parent( aq_inner(self) ) +portal = aq_inner(self) +while True: +portal = getattr(portal, 'aq_parent', None) +if portal is None: +break +if ISiteRoot.providedBy(portal): +return portal +# Portal could not be found, log an error or raise one? +return aq_inner(self) security.declarePublic('getRelativeContentPath') def getRelativeContentPath(self, content): ___ 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