[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
[Zope-CMF] CMF Tests: 8 OK, 1 Failed
Summary of messages to the cmf-tests list. Period Sat Jan 6 12:00:00 2007 UTC to Sun Jan 7 12:00:00 2007 UTC. There were 9 messages: 9 from CMF Unit Tests. Test failures - Subject: FAILED (failures=1) : CMF-1.5 Zope-2.8 Python-2.3.6 : Linux From: CMF Unit Tests Date: Sat Jan 6 21:46:16 EST 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-January/003732.html Tests passed OK --- Subject: OK : CMF-1.5 Zope-2.7 Python-2.3.6 : Linux From: CMF Unit Tests Date: Sat Jan 6 21:44:46 EST 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-January/003731.html Subject: OK : CMF-1.5 Zope-2.9 Python-2.4.4 : Linux From: CMF Unit Tests Date: Sat Jan 6 21:47:46 EST 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-January/003733.html Subject: OK : CMF-1.6 Zope-2.8 Python-2.3.6 : Linux From: CMF Unit Tests Date: Sat Jan 6 21:49:16 EST 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-January/003734.html Subject: OK : CMF-1.6 Zope-2.9 Python-2.4.4 : Linux From: CMF Unit Tests Date: Sat Jan 6 21:50:46 EST 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-January/003735.html Subject: OK : CMF-2.0 Zope-2.9 Python-2.4.4 : Linux From: CMF Unit Tests Date: Sat Jan 6 21:52:17 EST 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-January/003736.html Subject: OK : CMF-2.0 Zope-2.10 Python-2.4.4 : Linux From: CMF Unit Tests Date: Sat Jan 6 21:53:47 EST 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-January/003737.html Subject: OK : CMF-trunk Zope-2.10 Python-2.4.4 : Linux From: CMF Unit Tests Date: Sat Jan 6 21:55:17 EST 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-January/003738.html Subject: OK : CMF-trunk Zope-trunk Python-2.4.4 : Linux From: CMF Unit Tests Date: Sat Jan 6 21:56:47 EST 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-January/003739.html ___ 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] CMF Collector: Open Issues
The following supporters have open issues assigned to them in this collector (http://www.zope.org/Collectors/CMF). Assigned and Open mhammond - "Windows DevelopmentMode penalty in CMFCore.DirectoryView", [Accepted] http://www.zope.org/Collectors/CMF/366 Pending / Deferred Issues - "FSPropertiesObject.py cannot handle multiline input for lines, text attributes", [Deferred] http://www.zope.org/Collectors/CMF/271 - "Can't invalidate skin items in a RAMCacheManager", [Pending] http://www.zope.org/Collectors/CMF/343 - "workflow notify success should be after reindex", [Deferred] http://www.zope.org/Collectors/CMF/389 - "Possible bug when using a BTreeFolder Member folder", [Pending] http://www.zope.org/Collectors/CMF/441 - "Proxy Roles not Working/Applied to Worflow Transition Scripts", [Pending] http://www.zope.org/Collectors/CMF/449 - "safe_html filters some tags which should probably not be filtered", [Pending] http://www.zope.org/Collectors/CMF/452 - "purge_old in runAllImportSteps not working", [Pending] http://www.zope.org/Collectors/CMF/455 - "PUT handling for Events is broken", [Pending] http://www.zope.org/Collectors/CMF/458 - "Danger from Caching Policy Manager", [Pending] http://www.zope.org/Collectors/CMF/460 Pending / Deferred Features - "Favorite.py: queries and anchors in remote_url", [Pending] http://www.zope.org/Collectors/CMF/26 - "DefaultDublinCore should have Creator property", [Pending] http://www.zope.org/Collectors/CMF/61 - "Document.py: universal newlines", [Pending] http://www.zope.org/Collectors/CMF/174 - "portal_type is undefined in initialization code", [Pending] http://www.zope.org/Collectors/CMF/248 - "CMFTopic Does Not Cache", [Deferred] http://www.zope.org/Collectors/CMF/295 - "Wishlist: a flag that tags the selected action.", [Pending] http://www.zope.org/Collectors/CMF/301 - "CMFDefault should make use of allowCreate()", [Pending] http://www.zope.org/Collectors/CMF/340 - "Nested Skins", [Deferred] http://www.zope.org/Collectors/CMF/377 - "CatalogVariableProvider code + tests", [Pending] http://www.zope.org/Collectors/CMF/378 - "manage_doCustomize() : minor additions", [Pending] http://www.zope.org/Collectors/CMF/382 - "CMF needs View-based TypeInformation", [Pending] http://www.zope.org/Collectors/CMF/437 - "Marker attributes should be deprecated", [Pending] http://www.zope.org/Collectors/CMF/440 ___ 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
