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
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
[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
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
-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 Designhttp://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
[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
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
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
[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
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
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
[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
[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 we will have to
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
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
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
[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
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
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
[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:
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
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
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
-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 Designhttp://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
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) TranslationServiceTool at translation_service getUtility(ITranslationServiceTool, context=app.test).aq_parent Traceback (most recent call last): File stdin, line 1, in ? AttributeError: aq_parent from Products.CMFCore.utils import getToolByName getToolByName(app.test, 'translation_service') TranslationServiceTool at /test/translation_service getToolByName(app.test, 'translation_service').aq_chain [TranslationServiceTool at /test/translation_service, PloneSite at /test, Application at ] 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 [TranslationServiceTool at /test/translation_service, PloneSite at /test, Application at ] 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: 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
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
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
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
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: 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
