[Zope-CMF] Re: DirectoryView, GenericSetup/skins, CMF 2.1
Hi Rocky! Rocky Burt wrote: Perhaps a patch from my side would more adequately explain what it is I'm trying to accomplish. I've attached the patch to this message. The only thing that is missing (for me) is tests at this point. +1 for fixing this, but may I suggest another approach? 'minimal_fp' is a registry key created by 'utils.minimalpath'. Right now 'DirectoryView._dirpath' contains this registry key and I'd prefer to keep it like that. 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 While it doesn't make sense to store full/path/to/MyPackage/skins/my_skin in 'DirectoryView._dirpath' MyPackage/skins/my_skin would work fine. All we need is a migration 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. 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
[Zope-CMF] Re: DirectoryView, GenericSetup/skins, CMF 2.1
Hi Yuppie! On Sun, 2006-09-07 at 13:46 +0200, yuppie wrote: +1 for fixing this, but may I suggest another approach? 'minimal_fp' is a registry key created by 'utils.minimalpath'. Right now 'DirectoryView._dirpath' contains this registry key and I'd prefer to keep it like that. This is fine. I'd have to admit I don't totally grok all of the implementation details for DirectoryView and the registry at this point. So anything that more properly fits the current design gets a +1 from me. 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. While it doesn't make sense to store full/path/to/MyPackage/skins/my_skin in 'DirectoryView._dirpath' MyPackage/skins/my_skin would work fine. All we need is a migration path. Indeed. But given my little knowledge at this point I'm not sure what the migration path would look like. 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) 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 :/ Thanks, 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: DirectoryView, GenericSetup/skins, CMF 2.1
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
