[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 - Wrong cache association for FSObject, [Pending] http://www.zope.org/Collectors/CMF/255 - CMFSetup: Windows exports contain CR/LF, LF and even CR newlines, [Pending] http://www.zope.org/Collectors/CMF/266 - 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 - CMFSetup: Workflow Tool export fails with workflows which have scripts, [Pending] http://www.zope.org/Collectors/CMF/373 - CMFCore.Skinnable.SkinnableObjectManager can merge skin data, [Pending] http://www.zope.org/Collectors/CMF/375 - Proxy Roles does't work for a Script using portal_catalog.searchResults, [Pending] http://www.zope.org/Collectors/CMF/380 - workflow notify success should be after reindex, [Pending] http://www.zope.org/Collectors/CMF/389 - 'except ...: pass' in CMFCore/TypesTool.py:_queryFactoryMethod() nullifies VerboseSecurity, [Pending] http://www.zope.org/Collectors/CMF/410 - Possible bug when using a BTreeFolder Member folder, [Pending] http://www.zope.org/Collectors/CMF/441 - Possible bug when using a BTreeFolder Members folder, [Pending] http://www.zope.org/Collectors/CMF/442 - Possible bug when using a BTreeFolder Member folder, [Pending] http://www.zope.org/Collectors/CMF/443 - Possible bug when using a BTreeFolder Members folder, [Pending] http://www.zope.org/Collectors/CMF/444 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 - path criteria on Topic should honor VHM, [Pending] http://www.zope.org/Collectors/CMF/111 - Document.py: universal newlines, [Pending] http://www.zope.org/Collectors/CMF/174 - Add condition for transition's action like other action, [Pending] http://www.zope.org/Collectors/CMF/207 - Major action enhancement, [Pending] http://www.zope.org/Collectors/CMF/232 - 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
[Zope-CMF] Re: DirectoryView, GenericSetup/skins, CMF 2.1
Hi Yuppie, Just checking in to see if you got any of this put in place yet. Also hoping you can identify anything I need to do to ensure I can use skins with productless products :) - Rocky On Sun, 2006-09-07 at 21:59 +0200, yuppie wrote: Hi Rocky! Rocky Burt wrote: On Sun, 2006-09-07 at 13:46 +0200, yuppie wrote: The keys generated by 'utils.minimalpath' currently look like this: MyProduct/skins/my_skin full/path/to/MyPackage/skins/my_skin But we could change 'utils.minimalpath' to generate keys like these: Products/MyProduct/skins/my_skin MyPackage/skins/my_skin If we're changing how the keys look, why not simply use full package names in front with relative paths after the first slash (although I might prefer a colon or something in place of the first slash). So the new keys would be: Products.MyProduct/skins/my_skin some.long.package/skins/my_skin No need to make exception for Products in my opinion. And the retrieval logic would convert the first portion (before the first slash, or as I mentioned earlier, perhaps a colon) into an absolute path based on the actual package filesystem location. I did not want to make an exception for Products. For 'some.long.package' this would be the registry key: some/long/package/skins/my_skin But after looking again at the code I see why you propose to separate the module from the module-relative path: The FS* objects store minimal_fp in _filepath. This makes it necessary to convert minimal_fp back to the full path. AFAICS the code is unnecessary complex, we can store the full path in _filepath instead. The platform independent minimal_fp is only necessary for persistent objects. If there are no objections I'll change that on the trunk. With that change 'minimal_fp' becomes just a simple registry key without any need to convert it back to a real path. We can use the same pattern as for GenericSetup's registerProfile: Omitting 'Products/' would become deprecated. For backwards compatibility DirectoryInformations are first looked up with a Products/ prefix and if no DirectoryInformation is registered for that key the plain 'DirectoryView._dirpath' is looked up. With this lookup order MyPackage/skins/my_skin is masked by Products/MyPackage/skins/my_skin, but I guess we can live without support for that rare case until we remove the BBB code. Well, if we switch to colon's to separate package from relative path then we could still support the old and new way with no masking necessary (ie Products.MyProduct:skins/my_skin) I see your point, but if I change the value stored in _filepath we no longer need to know which part of minimal_fp represents the module. And I'd prefer the same format as in GenericSetup's registerProfile because it avoids confusion. As I mentioned already I think we can live with the masking issue for a while. And since you understand the problem so well and it only took me about 20min yesterday to come up with my initial patch... any chance you could implement the changes necessary for this? Otherwise I'll have to flounder about until I understand the minimal_fp thing a bit more :/ If I have fixed the _filepath issue there is not much left you need to understand. minimal_fp is a simple dictionary key based on the directory path. The keys you proposed make sense to me, I just would prefer to keep this in sync with registerProfile. Cheers, Yuppie ___ 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 -- 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: DirectoryView, GenericSetup/skins, CMF 2.1
Hi Rocky! Rocky Burt wrote: Just checking in to see if you got any of this put in place yet. Also hoping you can identify anything I need to do to ensure I can use skins with productless products :) I'm done with my part: http://svn.zope.org/?view=revrev=69063 AFAICS this needs to be done: 1.) Writing a new function for creating registry keys that replaces 'minimalpath'. 2.) Writing BBB code for persistent registry keys. Most DirectoryView objects are not persistent. Only DirectoryView.__of__() has to handle old keys stored in DirectoryView._dirpath. And it would be nice if GenericSetup would update the keys on import. 3.) Maybe it makes the code easier to read if 'minimal_fp' is replaced by something like 'reg_key'. 4.) Maybe utils.minimalpath and utils.expandpath should be marked as deprecated. AFAICS they are not used for other purposes. Cheers, Yuppie ___ 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
