The XML layer system in core.startup supports attachement of display name and icon to each file. However for many
situations, this is not enough, we need more localized values than one. That is why I suggest to have a bundlevalue,
which would lookup the correct bundle and then used the key to read the right localized value:
<attr name="loc" bundlevalue="key"/>
The question is where to get the bundle. Maybe relative to the XMLFS file, maybe a special attribute "bundle" or
fallback to SFS.localizedBundle value...
<attr name="displayName" bundlevalue="some.pkg.and.Bundle#Something.displayName"/>
which would get the value from
Nice simplification. Plus, in order to lower the amount of cached strings, we might support:
<attr name="displayName" bundlevalue="#Something.displayName"/>
which would mean Bundle in the same package as the the layer file. But this is not really necessary, if we find it
hard to implement.
Agreed that bundlevalue="#Something.displayName" would be a nice abbreviation for the common case, if it can be
implemented reasonably. I am not really sure how you would do that, though.
If you knew the "package name" of the layer, then XMLMapAttr (?) would just need to be passed this info; but this is not
trivial: easy for jar:/.../nbbuild/netbeans/cluster/x.jar!/p/l.xml => "p.Bundle", hard for
file:/...x/build/classes/p/l.xml => ???
You could find the desired URL of the English bundle, e.g. jar:/.../nbbuild/netbeans/cluster/x.jar!/p/Bundle.properties,
but this does not help you at all to find localizing overrides.
Perhaps you could take the layer URL and search path prefixes for a folder URL containing a META-INF/MANIFEST.MF whose
OpenIDE-Module-Layer entry matches the actual URL, and infer the desired package name from this. Would probably be
robust, though it seems hackish and would need to be explicitly documented since XMLFileSystem otherwise does not care
where layers are located.
ParsingLayerCacheManager would also need to be changed in order for the new value type to actually work outside unit
tests. WritableXMLFileSystem could be changed too, though I don't know if it is really necessary.
Another possible abbreviation would be
<attr name="displayName" bundlevalue="some.pkg.and.Bundle"/>
which would be a bit similar to how SFS.lB works. Might be less clear, though.
We can also consider
<attr name="displayName" bundle="some.pkg.and.Bundle" key="Something.displayName"/>
since we control the DTD. (The DTD already doesn't allow you to express that there must be exactly one *value attribute.
Not sure if XML Schema can do that or not.) Would not be as concise but might be clearest, and would help reduce the
number of cached strings relative to my original proposal.
Created attachment 63531 [details]
Most trivial implementation
I've added a patch that supports
<attr name="..." bundlevalue="path.to.your.Bundle#key"/>
The implemenation is the most trivial, adds just few lines of code. The rest of the patch is rewrite of filesystems
TCK to support testability of XMLFileSystem like implementations.
No documentation yet, this patch is just for primary oversight. Please tell us what you think is missing.
You forgot to update BinaryCacheManager.ATTR_TYPES.
Use value.split("#", 2).
Created attachment 63994 [details]
To be integrated tomorrow
Unless there are objections I will integrate tomorrow.
Don't forget that new DTDs should be published in www/www/dtds (in CVS); and should be registered in xml/entities (in
this case from the o.n.core layer).
I've updated the www/www/dtds yesterday. Thanks for the hint with o.n.core.