[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 dreamcatcher - setChainForPortalTypes doesn't allow to set default chain, [Accepted] http://www.zope.org/Collectors/CMF/475 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 - purge_old in runAllImportSteps not working, [Pending] http://www.zope.org/Collectors/CMF/455 - Danger from Caching Policy Manager, [Pending] http://www.zope.org/Collectors/CMF/460 - properties setup handler: support for non-ascii strings, [Pending] http://www.zope.org/Collectors/CMF/468 - GenericSetup does not handle non-ascii data well, [Pending] http://www.zope.org/Collectors/CMF/471 - autocreation of catalog indexes, [Pending] http://www.zope.org/Collectors/CMF/472 - [GS] Error when choosing initial_configuration , [Pending] http://www.zope.org/Collectors/CMF/473 - setChainForPortalTypes doesn't allow to set 'Default' as workflow chain, [Pending] http://www.zope.org/Collectors/CMF/478 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 - CMF needs View-based TypeInformation, [Pending] http://www.zope.org/Collectors/CMF/437 - New getNextEvent Method, [Pending] http://www.zope.org/Collectors/CMF/462 ___ Zope-CMF maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: [dev] unresolved site manager related issues
On Wed, 11 Apr 2007 16:01:38 +0200 yuppie wrote: Godefroid Chapelle wrote: Jens Vagelpohl wrote: On 10 Apr 2007, at 10:30, yuppie wrote: c) improving five.lsm (Rocky) AFAICS this is an other attempt to resolve the same issue: http://mail.zope.org/pipermail/zope-cmf/2007-March/025708.html We have to decide which way to go. I prefer c) if it works, b) otherwise. Same here. c) first, then b). Strongly against a). Before the sprint, I have spent more than one day exploring (c) Rocky's proposal and did not get to anything satisfactory. The zope.interface.adapter.AdapterRegistry would need to be acquisition-aware. IOW, we would once again pollute Z3. Why isn't it sufficient to use a customized version of AdapterRegistry for five.lsm? If the direct lookup in the registry returns wrapped utilities, other site managers and registries don't have to be acquisition-aware. No? Briefly, the direct lookup will not wrap the utilities precisely because it is a direct lookup and will bypass the code that is supposed to wrap them. I try to elaborate below. First: I am entering this thread a little late so sorry if I reply inconsistently. I was however a signer of the original document which thinks describes things pretty good and spent enough time on the issue to understand a bit about it. Taking the risk of repeating things said earlier in this thread, I attempt to summarize my points. The root problem is that the z3 component lookup, in case site managers are chained, is accessing the data of the chained site managers directly and bypassing its code. Iow it does not matter whatever acquisition wrapping you add in five.lsm. If there is any other site manager that appears, and that is not inheriting directly from five.lsm (and why would it?), it will access the registry data from the sitemanager of five, but bypass the methods that would add the acquisition wrapping in five.lsm, and will use _its own_ methods for returning that data. Which means principles of object oriented programming are somewhat broken and actually if I had not spent a few days debugging this problem, I would not easily suppose or believe this even myself, but this seems to be the case. This is precisely why, imo, the proposed solution for making all site managers acquisition aware and inherit code conditionally from five.lsm, is *not* the correct path to follow. Sure we could change the code of all our existing components that implement site managers. We could do this with KSS for example, and the breakage would be gone. But then consider what happens if anyone else in the future, not knowing that from this moment it is illegal to use plain zope3 site managers, happens to implement one as described in The Book, or happens to adopt some working code from plain zope3 userspace? The result will not only be that the code that depends on this new site manager will be broken, the effect will be that _all_ the code that uses _any_ getUtility lookup and depends on acquisition will be misteriously broken at once! This is kind of unexpected and will be very difficult to debug, it will happen inevitably, in both the core products and in custom site developments. Of course the best solution would be neither a) b) or c), but if the z3 component registry behaved in the expected way and would use not only the data but also the overwritten lookup methods from the classes that implement a given registry. I don't know if this would be easily achieved but I would suppose that this would not happen soon. There must be good reason why it is implemented this way and would be quite a big change to alter this. So what remains is that practically the site manager registry lookup code cannot be customized from any given site manager, because there is no guarantee that the methods will be used or not, because this depends on the site manager chaining. Consequently we cannot use five.lsm either to add the acquisition wrapping in a consistent and transparent way, at the moment. At least not by overwriting the registry lookup code. There is also another side of the story and this is that imo CMF or any other code that builds upon Zope, must respect its autonomy, ie, should not break plain z3 code or put additional restrictions on legitime constructions usage. There is at least an independent occasion where we discovered CMF is doing that (I believe this would deserve a thread of its own, briefly we have a plain zope3 product kss.demo that cannot be added from the ZMI any more, because we get a 'main_template not found' and of course we have no main template - the problem in this case is that CMF is overwriting something that has an effect in the entire instance, not only inside a portal where it has authority.) So when choosing a decision, it would be also important to consider not causing a breakage or putting extra requirements on code that is otherwise legitime itself, because this is
[Zope-CMF] Re: [dev] unresolved site manager related issues
Hi! Philipp von Weitershausen wrote: yuppie wrote: Kapil's also right when he says that utilities by principle are context-less components. By principle all Zope 3 code might depend on setSite to work as expected. We just don't pass that 'site context' explicitly to the component as in Zope 2. I still don't buy that context argument. Utilities and tools both are used in the 'context' of a site. You just gave the definition of a tool, not the one of a utility. By 'site context' I don't mean an Zope 2 acquisition context or an adapter context. I mean the site specific local environment that is usually looked up based on setSite or provided by CMF tools. The only difference is how the knowledge about the site is used: Just for lookups or also for acquisition wrapping. If a tool needs to get to the site object in order to operate, it might not be such a good idea to convert it to a utility. It might make more sense as an adapter... What I'm saying is that the all tools are utilities now assumption might've been a bit too naive. Of course CMF tool interfaces have some methods we would not add to a new utility interface. But most of them would become views, and as long as we pass in the REQUEST explicitly they are still valid utility methods. I'm not aware of any tool methods that should be converted to site adapters. Most tools use the 'site context' just for the security machinery. The other reason why tools needed the context was looking up other tools, but that is obsolete in CMF 2.1 beta. I consider every other usage of the acquisition context a bug. Cheers, Yuppie ___ Zope-CMF maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: [dev] unresolved site manager related issues
Hi! Balazs Ree wrote: The root problem is that the z3 component lookup, in case site managers are chained, is accessing the data of the chained site managers directly and bypassing its code. Iow it does not matter whatever acquisition wrapping you add in five.lsm. If there is any other site manager that appears, and that is not inheriting directly from five.lsm (and why would it?), it will access the registry data from the sitemanager of five, but bypass the methods that would add the acquisition wrapping in five.lsm, and will use _its own_ methods for returning that data. Which means principles of object oriented programming are somewhat broken and actually if I had not spent a few days debugging this problem, I would not easily suppose or believe this even myself, but this seems to be the case. That code is hard to read, but AFAICS the lists and dictionaries in the AdapterRegistry (_adapters, _subscribers, _provided) are looked up directly. Did anybody try to use customized lists and dictionaries for five.lsm that do the wrapping? Or can anybody tell me why that would be a bad idea? I guess performance might be a problem. Cheers, Yuppie ___ Zope-CMF maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] CMF Tests: 9 OK, 2 Unknown
Summary of messages to the cmf-tests list. Period Wed Apr 11 12:00:00 2007 UTC to Thu Apr 12 12:00:00 2007 UTC. There were 11 messages: 11 from CMF Unit Tests. Unknown --- Subject: UNKNOWN : CMF-2.1 Zope-trunk Python-2.4.4 : Linux From: CMF Unit Tests Date: Wed Apr 11 21:35:38 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-April/004638.html Subject: UNKNOWN : CMF-trunk Zope-trunk Python-2.4.4 : Linux From: CMF Unit Tests Date: Wed Apr 11 21:38:38 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-April/004640.html Tests passed OK --- Subject: OK : CMF-1.5 Zope-2.7 Python-2.3.6 : Linux From: CMF Unit Tests Date: Wed Apr 11 21:23:37 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-April/004630.html Subject: OK : CMF-1.5 Zope-2.8 Python-2.3.6 : Linux From: CMF Unit Tests Date: Wed Apr 11 21:25:07 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-April/004631.html Subject: OK : CMF-1.5 Zope-2.9 Python-2.4.4 : Linux From: CMF Unit Tests Date: Wed Apr 11 21:26:37 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-April/004632.html Subject: OK : CMF-1.6 Zope-2.8 Python-2.3.6 : Linux From: CMF Unit Tests Date: Wed Apr 11 21:28:07 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-April/004633.html Subject: OK : CMF-1.6 Zope-2.9 Python-2.4.4 : Linux From: CMF Unit Tests Date: Wed Apr 11 21:29:37 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-April/004634.html Subject: OK : CMF-2.0 Zope-2.9 Python-2.4.4 : Linux From: CMF Unit Tests Date: Wed Apr 11 21:31:07 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-April/004635.html Subject: OK : CMF-2.0 Zope-2.10 Python-2.4.4 : Linux From: CMF Unit Tests Date: Wed Apr 11 21:32:38 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-April/004636.html Subject: OK : CMF-2.1 Zope-2.10 Python-2.4.4 : Linux From: CMF Unit Tests Date: Wed Apr 11 21:34:08 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-April/004637.html Subject: OK : CMF-trunk Zope-2.10 Python-2.4.4 : Linux From: CMF Unit Tests Date: Wed Apr 11 21:37:08 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-April/004639.html ___ Zope-CMF maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: [dev] unresolved site manager related issues
yuppie wrote: Philipp von Weitershausen wrote: yuppie wrote: Kapil's also right when he says that utilities by principle are context-less components. By principle all Zope 3 code might depend on setSite to work as expected. setSite() is something that influences the place (= registry) that we look up the utilities from. It doesn't influence the context of the utility because tilities have no context. Sure, utilities might be local and even persistent. But that is a registration detail, not an implementation detail. The name site in Zope 3 is confusing. Place with component registrations is better. So, let's pretend setSite() was called updateCurrentComponentRegistryFromPlace(), it becomes pretty obvious that it has nothing to do with what the utility does. All it does is tell the Component Architecture which component registry to look up things. The fact that this registry happens to be associated with a place in the object hierarchy is completely irrelevant to the Component Architecture. We just don't pass that 'site context' explicitly to the component as in Zope 2. Right. The utility doesn't even *get* the context (and it shouldn't need it.) And in Zope 2 we don't pass the context in either. The tools get it by doing aq_parent(). This should be converted to a lookup, because it's not about the hierarchy that the tool happened to be placed in, it's about getting one very specific object: the CMF site. I still don't buy that context argument. Utilities and tools both are used in the 'context' of a site. You just gave the definition of a tool, not the one of a utility. By 'site context' I don't mean an Zope 2 acquisition context or an adapter context. I mean the site specific local environment that is usually looked up based on setSite or provided by CMF tools. Utilities shouldn't care which site context they've been registered at. If they want a specific object like the CMF site they should look it up. The only difference is how the knowledge about the site is used: Just for lookups or also for acquisition wrapping. If a tool needs to get to the site object in order to operate, it might not be such a good idea to convert it to a utility. It might make more sense as an adapter... What I'm saying is that the all tools are utilities now assumption might've been a bit too naive. Of course CMF tool interfaces have some methods we would not add to a new utility interface. But most of them would become views, and as long as we pass in the REQUEST explicitly they are still valid utility methods. I'm not aware of any tool methods that should be converted to site adapters. Most tools use the 'site context' just for the security machinery. The other reason why tools needed the context was looking up other tools, but that is obsolete in CMF 2.1 beta. I consider every other usage of the acquisition context a bug. Good. Then fix those bugs and we no longer need any acquisition wrapping of local utilities at all (and it should be ripped out of five.localsitemanager again). This would, of course, be an acceptable solution. -- http://worldcookery.com -- Professional Zope documentation and training ___ Zope-CMF maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: [dev] unresolved site manager related issues
Alec Mitchell wrote at 2007-4-12 06:59 -0700: ... ... deprecation of getToolByName ... which is that there's no practical reason other than aesthetics to deprecate getToolByName at this point. A very good point: let's deprecate deprecations done just for aethetical reasons :-) This still seems like we're creating a lot of developer pain with minimal benefit (tools already allow for local customization by acquisition). for precisely this reason. -- Dieter ___ Zope-CMF maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Modifications using GS profiles
Tres Seaver wrote: yuppie wrote: BTW: Are there any unit tests for the upgrade steps feature? I'll defer to Rob: he was porting the code from the CPS add-on. okay, i've gotten things to a reasonable place, committed on the tseaver-bbq_sprint branch. there are tests for the upgrade step zcml directives and the upgrade step registry (in test_zcml.py). there aren't yet tests for the setup tool code that lists and performs the upgrades, however. once those are written, i reckon it'd be ready to merge to trunk. i'll work on those next, but things have gotten pretty busy for me, i might not be able to get to them until next week. things are in good enough shape for someone else to pick up the thread, though, if desired. -r ___ Zope-CMF maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: [dev] unresolved site manager related issues
Alec Mitchell wrote: On 4/11/07, yuppie [EMAIL PROTECTED] wrote: Hi! Kapil Thangavelu wrote: On Tue, 10 Apr 2007 09:09:27 -0400, Jens Vagelpohl [EMAIL PROTECTED] wrote: On 10 Apr 2007, at 10:30, yuppie wrote: Currently non-five.lsm site managers don't work in CMF, see this thread: http://mail.zope.org/pipermail/zope-cmf/2007-March/025817.html Proposed solutions: a) reverting most 'tools as utilities' changes (Kapil) http://mail.zope.org/pipermail/zope-cmf/2007-March/025817.html b) supplementing five.lsm (Hanno) http://mail.zope.org/pipermail/zope-cmf/2007-March/025822.html c) improving five.lsm (Rocky) AFAICS this is an other attempt to resolve the same issue: http://mail.zope.org/pipermail/zope-cmf/2007-March/025708.html We have to decide which way to go. I prefer c) if it works, b) otherwise. Same here. c) first, then b). Strongly against a). are we juding by the amount of work to fix the 'fix'/problem or by the nature of the solution itself. I'm judging by the solution itself *and* by the fact that we made a decision long ago and released a beta based on that decision. We should reverse that decision only if we are sure it was a mistake. I feel very strongly that this decision was a mistake, and regret that I didn't get involved in the initial discussions. As a result, I'm very much in favor of a. i'll add yet another me too to this chorus. removing getToolByName has become considerably more trouble than it's worth. currently, i see basically two options being suggested: - adding (and then living with) yet more code in Five, which changes the behaviour of clean, well established Z3 idioms in order to support Z2 components which require acquisition. - undeprecating an extremely widely used, intended-to-be-future-proof Z2 idiom, which would allow us to interact more simply and predictably with existing Z3 utility lookup code i guess it's pretty clear which one i support. ;-) -r ___ Zope-CMF maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
