[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 jens - CachingPolicyManager: Support OFS.Cache.CacheManager, [Accepted] http://www.zope.org/Collectors/CMF/408 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 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
Re: [Zope-CMF] Tools as local utilities
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 9 Sep 2006, at 22:57, Martin Aspeli wrote: philiKON pointed out something interesting to me the other day - we could actually register the existing tools as local utilities as of Zope 2.10. That way, you could do this: This sounds fine, but we'd probably want to wait until we have a CMF version that does require 2.10, right? HEAD says Zope = 2.9. Unless we want to work with indirections that know how to do the right thing. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Darwin) iD8DBQFFA++kRAx5nvEhZLIRAmJrAJsHX19fFYxkKIOZgK9EFw7FHmD+MwCgkThR kmkvGhCpZFf0FVPwGuABHHg= =H+ve -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: Tools as local utilities
On Sun, 2006-10-09 at 12:57 +0200, Jens Vagelpohl wrote: On 9 Sep 2006, at 22:57, Martin Aspeli wrote: philiKON pointed out something interesting to me the other day - we could actually register the existing tools as local utilities as of Zope 2.10. That way, you could do this: This sounds fine, but we'd probably want to wait until we have a CMF version that does require 2.10, right? HEAD says Zope = 2.9. Unless we want to work with indirections that know how to do the right thing. I guess as far as the Plone community is concerned having CMF 2.1 require Zope 2.10 would be no problem since the next release of Plone will require Zope 2.10. Of course I'm not going to be naive enough to think just because it's ok for the Plone community it's good enough for all other CMF consumers :) - Rocky -- Rocky Burt ServerZen Software -- http://www.serverzen.com News About The Server (blog) -- http://www.serverzen.net signature.asc Description: This is a digitally signed message part ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Tools as local utilities
On Sat, 2006-09-09 at 21:57 +0100, Martin Aspeli wrote: Hi guys, philiKON pointed out something interesting to me the other day - we could actually register the existing tools as local utilities as of Zope 2.10. That way, you could do this: actions = getUtility(IActionsTool) as another spelling for actions = getToolByName(context, 'portal_actions') But now we're being more consistent with Zope 3, we are using a proper interface and not just a string to check, we don't have to worry about passing a context parameter (though tests have to do a setSite() call), and we can let the registration be overridden with the component registry operations. +10 on this idea from me. The important thing would be to make sure the getToolByName deprecation message is smart enough to describe the exact necessary getUtility call. In other words use getToolByName(context, 'portal_properties') has been deprecated, please use getUtility(IPropertiesTool) instead rather than the confusing getToolByName has been deprecated, please use getUtility instead. - Rocky -- Rocky Burt ServerZen Software -- http://www.serverzen.com News About The Server (blog) -- http://www.serverzen.net signature.asc Description: This is a digitally signed message part ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: Tools as local utilities
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10 Sep 2006, at 14:53, Rocky Burt wrote: This sounds fine, but we'd probably want to wait until we have a CMF version that does require 2.10, right? HEAD says Zope = 2.9. Unless we want to work with indirections that know how to do the right thing. I guess as far as the Plone community is concerned having CMF 2.1 require Zope 2.10 would be no problem since the next release of Plone will require Zope 2.10. Of course I'm not going to be naive enough to think just because it's ok for the Plone community it's good enough for all other CMF consumers :) Just out of curiosity, which dependencies does Plone 3.0 have that require Zope 2.10? Or was it some papal edict to use 2.10? jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Darwin) iD8DBQFFBA2rRAx5nvEhZLIRAhMEAJ4gelM/yEyqJEYx4mJ3ozsTSOf8yACcCMqh xlBPI4+Vt71pXyJp00zP5e4= =xpPv -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: Tools as local utilities
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rocky Burt wrote: On Sat, 2006-09-09 at 21:57 +0100, Martin Aspeli wrote: Hi guys, philiKON pointed out something interesting to me the other day - we could actually register the existing tools as local utilities as of Zope 2.10. That way, you could do this: actions = getUtility(IActionsTool) as another spelling for actions = getToolByName(context, 'portal_actions') But now we're being more consistent with Zope 3, we are using a proper interface and not just a string to check, we don't have to worry about passing a context parameter (though tests have to do a setSite() call), and we can let the registration be overridden with the component registry operations. +10 on this idea from me. +1 here, too. In fact, being able to make this switch is the *reason* 'getToolByName' was introduced in the first placey. The important thing would be to make sure the getToolByName deprecation message is smart enough to describe the exact necessary getUtility call. In other words use getToolByName(context, 'portal_properties') has been deprecated, please use getUtility(IPropertiesTool) instead rather than the confusing getToolByName has been deprecated, please use getUtility instead. I think we are likely to modify 'getToolByName' to use a registry of names to utility interfaces for all the known names, falling back to getattr only for unknown ones. In that case, the deprecation message can supply either the name of the interface, or at least say that the name is not a known tool name. Tres. - -- === Tres Seaver +1 202-558-7113 [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 iD8DBQFFBBxJ+gerLs4ltQ4RAr6/AKCyhPoKGODtwUg5rVdo639YfbTeWACfcIt3 pZw9Eewu+EWXMhLvPKbajAg= =K23L -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: Tools as local utilities
Hi. Jens Vagelpohl wrote: Just out of curiosity, which dependencies does Plone 3.0 have that require Zope 2.10? Or was it some papal edict to use 2.10? It was more of an edict, to catch up with the latest versions of our underlying frameworks again. The two things we are actually relying on right now is OOTB support for egg-enabled Python packages instead of Zope products (there are some egg-enabled plone.* and plone.app.* packages) and quite some of these packages are using the new local components API. We are also going to use formlib based forms, contentmanagers and viewlets and finally zope.testbrowser based tests but these are available in Zope 2.9 with Five 1.4 as well. Apart from these supporting only Zope 2.10 made it possible to remove quite some BBB code for changed package locations ;) As a final note I might add that we still consider to support Zope 2.11 as well for Plone 3.0 especially if it brings us Blob support on the ZODB level. 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 release schedule
Hi. Jens Vagelpohl wrote: I was under the impression there were a few show-stoppers that needed CMF 2.1 (and in some cases Five) support that weren't there yet, like the customize a skin item. Are there any items you know are missing? You seem to apply you have everything you need. The current state of the CMF 2.1 support for Plone 3.0 is simply at the it-works level. That is, I made all those changes that where required to get all tests passing again. The major change here was porting all actions related code to the new IAction and IActionCategory code, which was especially painful for our huge amount of migration code. The second major change was porting quite some amount of code for registering new content types to be based on GenericSetup profiles, as I found this to be the only reliable way to register new types. Regarding the skin customizations our current strategy is to write views in pure file-system based code without a way to customize these TTW and have the page templates as usual skin items with customize support. While this isn't ideal we are currently mainly moving code out of tools into views and utilities. Both of these increase the ability to make customizations compared to the former state of having to replace complete tools. Looking at http://www.zope.org/Products/CMF/docs/roadmap there are quite a few items we were hoping to get in that aren't finished yet. OK, to be honest: None of the items in the CMF roadmap are crucial to the next Plone release in any way. So for the three remaining items: Eggs As we won't be able to move Plone to be completely egg-based we do not need CMF to be either. But of course we want to make as much of Plone available as an egg as possible in the future, maybe in the next release which is planned for autumn 2007 (Plone 3.0 final is scheduled for late March 2007). Note that this is however not a priority as we depend on quite some external binaries, so we won't be able to do a pure egg-based install anyways. Zope3 views --- Having good Zope3 views in CMF would be nice as it would eventually enable us to re-use some of these again. But honestly right now we do not use any of the content types from CMF anymore apart from being based on the PortalContent base class. We do not use any of the skin layers from CMF and the only skin script we still use is the titleOrId script which is more than trivial. So having views on the CMF level might open up a possibility to re-use some of them again, but whether or not these are present does not have any immediate effect on Plone. Events -- This is the only item that has a direct effect on our code. The extremely ugly way we dealt with the added events and removed manage* methods so far is to copy over the manage* methods to Archetypes instead, as we cannot break all dependent products without concrete deprecation warnings and nobody had the time to add proper events support to Archetypes so far. This resulted in a even more insane cataloging behavior of Archetypes which we circumvented by looking if an object is already in a catalog before indexing it and looking if it is still there before unindexing it. Reindexing objects still takes place quite some times. As the amount of people working on Archetypes right now is fairly limited, I guess we will deal with most other events in the same manner. While this is ugly it was the only way to get Archetypes working with CMF 2.1 so far. So while more events are theoretically nice, we won't take advantage of them right now. Some of the above might only be my personal opinion and I'll let others jump in if they have a different point of view :) Yours, Hanno P.S. We'll hopefully meet in St. Augustin next week ;) ___ 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: Tools as local utilities
Jens Vagelpohl wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10 Sep 2006, at 14:53, Rocky Burt wrote: This sounds fine, but we'd probably want to wait until we have a CMF version that does require 2.10, right? HEAD says Zope = 2.9. Unless we want to work with indirections that know how to do the right thing. I guess as far as the Plone community is concerned having CMF 2.1 require Zope 2.10 would be no problem since the next release of Plone will require Zope 2.10. Of course I'm not going to be naive enough to think just because it's ok for the Plone community it's good enough for all other CMF consumers :) Just out of curiosity, which dependencies does Plone 3.0 have that require Zope 2.10? Or was it some papal edict to use 2.10? 2.10 really is lovely, because Zope 3.3 is lovely. :) The local components story is much, much better. Look at Hanno's GSLocalAddOns package (which really should move to CMFCore once CMFCore is happy to require 2.10+), or other examples. Basically, it solves a lot of the problems we had with 2.9 and earlier in that it was hard to make things installable into a CMF site - a global utility or adapter was an either-or proposition for all sites in a Zope instance. Being able to use local adapters (and local event handlers) is also very useful. Plus, the whole story around formlib, zope.contentprovider, zope.viewlet is improved, (these three tools are great - if you haven't played with them, go read the doctests, or Rocky's formlib tutorial on plone.org) and Five has caught up to these to make them accessible to us. 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
