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
