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.

Bug 138076 - Support for localized attributes in XMLFS
Summary: Support for localized attributes in XMLFS
Status: RESOLVED FIXED
Alias: None
Product: platform
Classification: Unclassified
Component: Filesystems (show other bugs)
Version: 6.x
Hardware: All All
: P3 blocker (vote)
Assignee: Jaroslav Tulach
URL:
Keywords: API_REVIEW_FAST
Depends on:
Blocks:
 
Reported: 2008-06-24 12:57 UTC by Jaroslav Tulach
Modified: 2008-12-22 11:48 UTC (History)
4 users (show)

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:


Attachments
Most trivial implementation (34.02 KB, patch)
2008-06-26 17:54 UTC, Jaroslav Tulach
Details | Diff
To be integrated tomorrow (44.59 KB, patch)
2008-07-07 13:42 UTC, Jaroslav Tulach
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jaroslav Tulach 2008-06-24 12:57:37 UTC
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...
Comment 1 Jesse Glick 2008-06-24 20:32:48 UTC
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")
Comment 2 Jaroslav Tulach 2008-06-24 21:14:01 UTC
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.
Comment 3 Jesse Glick 2008-06-24 21:34:11 UTC
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.
Comment 4 Jaroslav Tulach 2008-06-26 17:54:52 UTC
Created attachment 63531 [details]
Most trivial implementation
Comment 5 Jaroslav Tulach 2008-06-26 17:57:25 UTC
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.
Comment 6 Jesse Glick 2008-06-26 19:40:21 UTC
You forgot to update BinaryCacheManager.ATTR_TYPES.

Use value.split("#", 2).
Comment 7 Jaroslav Tulach 2008-07-07 13:42:33 UTC
Created attachment 63994 [details]
To be integrated tomorrow
Comment 8 Jaroslav Tulach 2008-07-07 13:43:41 UTC
Unless there are objections I will integrate tomorrow.
Comment 9 Max Sauer 2008-07-07 14:20:55 UTC
Thanks yardo.
Comment 10 Jesse Glick 2008-07-08 01:27:36 UTC
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).
Comment 11 Jaroslav Tulach 2008-07-08 07:58:16 UTC
89838624d803: Integrated.

I've updated the www/www/dtds yesterday. Thanks for the hint with o.n.core.