Bug 111361 - PlatformsCustomizer does not allow to change the category display name
PlatformsCustomizer does not allow to change the category display name
Status: NEW
Product: java
Classification: Unclassified
Component: Platform
6.x
All All
: P1 (vote)
: TBD
Assigned To: Tomas Zezula
issues@java
: API, API_REVIEW_FAST
Depends on:
Blocks: 101486 132217
  Show dependency treegraph
 
Reported: 2007-07-30 15:29 UTC by Adam Sotona
Modified: 2011-11-28 18:26 UTC (History)
3 users (show)

See Also:
Issue Type: ENHANCEMENT
:


Attachments
Patch for this issue (6.56 KB, patch)
2009-07-18 21:14 UTC, _ tboudreau
Details | Diff
Jesse is correct, this can be done with compatible addition to Specification (16.28 KB, patch)
2009-08-03 21:10 UTC, _ tboudreau
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Adam Sotona 2007-07-30 15:29:15 UTC
PlatformsCustomizer does not allow to change the category display name.
For the case see dependent issue.
Comment 1 Tomas Zezula 2007-09-05 16:45:30 UTC
New API usecase request => enhancement.
Comment 2 _ tboudreau 2008-11-19 17:13:48 UTC
Issue 132217 is use case. Can we either do this or can you close this as wontfix and I'll close 132217 the same way?
Comment 3 Tomas Zezula 2008-11-19 17:40:34 UTC
It will require change of the API, the platform's Specification which contains the type has nothing like display type. Unfortunately I will have no time to do this 
into 7.0 as I am fully assigned to java core and parsing api.
If you think it's not important feel free to close it.

Comment 4 Adam Sotona 2008-11-20 08:10:04 UTC
I agree, but if we close it, we will get it reported back in a few days.
JavaFX has already two reports on this issue, both low priority.
Feel free to decide, I'll follow.
Comment 5 _ tboudreau 2008-11-20 15:26:21 UTC
See suggested resolution in issue 101486.  Need to test it, but it should work for some other module (or java.project)
to define the J2ME folder and localize it to "Java ME", then have a kit module hide the folder.  When the first mobility
platform is added, the folder is unhidden, but it should (?) still have the localization attributes from the original layer.

At worst this could be handled with an ugly but easy-to-do, reliable hack:  java.platform notices if a folder called
J2ME is created (the UI must be listening for file changes already);  if so, it immediately sets its localizing bundle
attribute so the name is correct.  Not pretty, but no reason it wouldn't work forever.
Comment 6 _ tboudreau 2008-11-25 22:50:48 UTC
Suggestion won't work.  Need Specification.getDisplayName().
Comment 7 _ tboudreau 2009-07-18 21:14:11 UTC
Created attachment 84898 [details]
Patch for this issue
Comment 8 _ tboudreau 2009-07-18 21:17:12 UTC
The attached patch adds a trivial API class
public class SpecificationLocalizer {
  ...
  public String getName (String specificationName);
}

and adds one instance to the default lookup which converts J2SE -> Java SE and J2ME -> Java ME

It is a compatible addition, and solves the problem with minimal code changes.
Comment 9 Jesse Glick 2009-07-29 14:58:31 UTC
[JG01] SpecificationLocalizer should be in an SPI package.


[JG02] getName and hence SpecificationLocalizer should be abstract. Impls should be in java.j2seplatform, mobility.*, etc.


[JG03] Would also need @since, apichanges.xml.


[JG04] Would want to see the code using this new method in the UI as part of the patch.


[JG04, to supersede JG01 and JG02] I'm not sure I even see the purpose of a separate service interface. Why not just add
an optional displayName parameter to the Specification constructors, and a getDisplayName getter? Certainly whatever
code is creating the Specification, generally the code creating the JavaPlatform, should know how to localize it. Seems
simpler and more consistent with the existing API.


BTW pay attention to your diffs and keep them clean:

-        public @Override String getDisplayName() {
+        public @Override String getDisplayName() {            /* gratuitous whitespace added here */
Comment 10 _ tboudreau 2009-08-03 21:10:42 UTC
Created attachment 85728 [details]
Jesse is correct, this can be done with compatible addition to Specification
Comment 11 _ tboudreau 2009-08-03 21:12:15 UTC
Attached patch adds constructors w/ display name parameter to Specification, and Specification.getDisplayName(); also
makes use of it for SE, ME, CDC and JavaCard projects;  and updates those modules dependencies to require v1.14 of
java.platform.  Testing it now.
Comment 12 Jesse Glick 2009-08-03 21:33:31 UTC
Looks simpler & better.


[JG06] displayName should follow, not precede, name in the constructor arg list. (For consistency with Node.Property,
Sources.genericGroup, and many other APIs.)


[JG07] The dep update should have been in mobility.cldcplatform, not mobility.project.


[JG08] For ease of analysis by source code traversal tools, please use constant strings for the key param to
NbBundle.getMessage.


[JG09] <summary></summary> should not be empty.
Comment 13 _ tboudreau 2009-08-08 05:35:40 UTC
> [JG08] For ease of analysis by source code traversal tools, please use constant strings for 
> the key param to NbBundle.getMessage.

@Jesse:  Do you really mean "please use", or "please do not use"?  Probably 98% of calls to NbBundle in NetBeans use
hardcoded strings, not constants, and if something is searching for missing bundle keys, that is certainly easier to
analyze.  Did you really mean that I *should* use constants?

Comment 14 Jesse Glick 2009-08-08 20:35:10 UTC
I meant "please use" but I should have specified that I meant hardcoded strings, i.e. constant values rather than Java
expressions. I.e. in place of

NbBundle.getMessage(J2MEPlatform.class, SPECIFICATION_NAME)

use

NbBundle.getMessage(J2MEPlatform.class, "j2me")

This makes it easier for analysis tools to look for missing or unused keys, etc., and also means that pelmel.kenai.com
can display the localized string inline in the editor.
Comment 15 Jesse Glick 2011-11-28 17:59:33 UTC
Still active?

JG08 should be revised to suggest @NbBundle.Messages.


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo