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

[Rocky Burt]

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 at 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
Url : http://mail.zope.org/pipermail/zope-cmf/attachments/20060713/b12da985/attachment.bin