[Zope-CMF] Re: DirectoryView, GenericSetup/skins, CMF 2.1
Dieter Maurer wrote: Rocky Burt wrote at 2006-7-9 10:11 -0230: ... 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. We have a Zope version where package resources (such as skins) can come together with the package from a zip archive (this is a function similar to the newer egg Python function). We identify such resources via pypackage urls which have the form pypackage:package/path Here package is the full package path (e.g. path.to.some.package). This is very similar to your proposal. I think, when we change something, we should look for a way that could survive eggification (planned for Zope 2.11). Something along your proposal might be a very good candidate! Please note that in CMF 2.1 this is just a registry key for looking up DirectoryInformations. It is no longer used for looking up the filesystem resources directly. The identifiers discussed here are useful for direct lookup, but IMHO they are overkill for registry lookup. 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
yuppie wrote at 2006-7-14 11:30 +0200: ... We have a Zope version where package resources (such as skins) can come together with the package from a zip archive (this is a function similar to the newer egg Python function). We identify such resources via pypackage urls which have the form pypackage:package/path Here package is the full package path (e.g. path.to.some.package). ... Please note that in CMF 2.1 this is just a registry key for looking up DirectoryInformations. It is no longer used for looking up the filesystem resources directly. The identifiers discussed here are useful for direct lookup, but IMHO they are overkill for registry lookup. When I remember right, the original question was how these keys are represented externally -- in a GenericSetup profile. And there, such a representation may well be adequate... -- 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: 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
[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
[Zope-CMF] Re: DirectoryView, GenericSetup/skins, CMF 2.1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rocky Burt wrote: I'm currently investigating registering DirectoryView's from regular python packages with GenericSetup+skins.xml. After debugging through this somewhat I have discovered that minimal paths described in skins.xml are made relative to $INSTANCE_HOME/Products. Obviously in a regular python package (living outside of Products) this means using minimal paths won't work. And of course since the actual location of the py package will vary from deployment to deployment, the logical approach would be to make the minimal path relative to the package home. Does anyone have any idea's on this? So far it looks like all other major cmf functionality can be used outside in a regular python package (living outside of Products). Perhaps I'm missing something? If this is indeed the case ... would you all entertain a proposal/patch from me providing a way to use skins from py packages that is b/w compatible with the current approach? Hmmm, I thought this was landed already: I worked that out back in November / December, I think, on the 'tseaver-pkg_resources' branch. 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 iD8DBQFEsAfU+gerLs4ltQ4RApVYAKC2cDcC5iNMPJwR8166dOd0Si78JwCgvMkT bMpnYoZXjsPHBUjv0lZ0vvE= =c4B9 -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: DirectoryView, GenericSetup/skins, CMF 2.1
On Sat, 2006-08-07 at 15:30 -0400, Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rocky Burt wrote: I'm currently investigating registering DirectoryView's from regular python packages with GenericSetup+skins.xml. After debugging through this somewhat I have discovered that minimal paths described in skins.xml are made relative to $INSTANCE_HOME/Products. Obviously in a regular python package (living outside of Products) this means using minimal paths won't work. And of course since the actual location of the py package will vary from deployment to deployment, the logical approach would be to make the minimal path relative to the package home. Does anyone have any idea's on this? So far it looks like all other major cmf functionality can be used outside in a regular python package (living outside of Products). Perhaps I'm missing something? If this is indeed the case ... would you all entertain a proposal/patch from me providing a way to use skins from py packages that is b/w compatible with the current approach? Hmmm, I thought this was landed already: I worked that out back in November / December, I think, on the 'tseaver-pkg_resources' branch. I just briefly inspected the tseaver-pkg_resources branch and I have a few questions/comments: 1. was this ever merged into trunk for cmf2.1 inclusion (my brief comparisons leads me to believe it was not) ? 2. it looks like the branch was put in place to make it so the cmf files themselves uses pkg_resources so they can be loaded from eggs and the like -- not that the paths pointed to by DirectoryViews could exist outside of Products (relative paths I mean) Perhaps I'm missing something? I'd welcome a technical explanation as to what exactly the branch tried to do and the ETA on inclusion into trunk. 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
