This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
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...
Perhaps <attr name="displayName" bundlevalue="some.pkg.and.Bundle#Something.displayName"/> which would get the value from NbBundle.getBundle(""some.pkg.and.Bundle").get("Something.displayName")
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 <folder name="x"> <folder name="y"> <file name="z"> <attr name="displayName" bundlevalue="some.pkg.and.Bundle"/> </> </> </> => NbBundle.getBundle("some.pkg.and.Bundle").getMessage("x/y/z#displayName") 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.
Thanks yardo.
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).
89838624d803: Integrated. I've updated the www/www/dtds yesterday. Thanks for the hint with o.n.core.