[Zope-CMF] Re: DirectoryView, GenericSetup/skins, CMF 2.1

[yuppie]

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