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:


But we could change 'utils.minimalpath' to generate keys like these:


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:

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:


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.



Zope-CMF maillist  -  Zope-CMF@lists.zope.org

See http://collector.zope.org/CMF for bug reports and feature requests

Reply via email to