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