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.
Summary: | Provide a transition plan for users of deprecated editors | ||
---|---|---|---|
Product: | platform | Reporter: | Rochelle Raccah <raccah> |
Component: | Property Editors | Assignee: | Jiri Rechtacek <jrechtacek> |
Status: | RESOLVED WONTFIX | ||
Severity: | blocker | CC: | jglick, jrechtacek |
Priority: | P3 | Keywords: | API |
Version: | 3.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | ENHANCEMENT | Exception Reporter: | |
Bug Depends on: | 29447 | ||
Bug Blocks: | 5278 | ||
Attachments: |
Patch adding new hintable, internationalizable editors for primitive boolean and int types
Patch revised per Jesse's comments & including unit test |
Description
Rochelle Raccah
2002-02-21 00:06:03 UTC
Ales, please add this to a editors transition's plan. Thanks Set target milestone to TBD Set target milestone to TBD IMHO could be WONTFIX - this property editor is so trivial it's stupid. In fact it is written much more verbosely than is really needed. Should suffice to have e.g.: public final class MyEd extends SimplePropertyEditor { private final Map const2Name = new HashMap(); private final Map name2Const = new HashMap(); { const2Name.put(new Integer(CONST1), "CONST1"); // etc. Iterator it = const2Name.entrySet().iterator(); while (it.hasNext()) { Map.Entry e = (Map.Entry)it.next(); name2Const.put(e.getValue(), e.getKey()); } } public String[] getTags() { return name2Const.keySet().toArray(new String[0]); } public String getAsText() { return const2Name.get(getValue()); } public void setAsText(String s) { setValue(name2Const.get(s)); } } Good 'nuff. But if desired, the prop ed for Integer.TYPE could indeed have a pair of hints in the form of an int[] and String[] to display as constants; not very hard to do. Sorry, what is SimplePropertyEditor and where is it defined? Does it handle the listeners? Sorry, PropertyEditorSupport. Re. listeners - I think calling setValue is all you need. I just noticed that the java module now has a private copy of the ChoicePropertyEditor class which looks mostly like the deprecated version but has a few simplications similar to the ones mentioned below (extends PropertyEditorSupport, no separate listener handling, etc.). So, should we all have private copies of this class? Doesn't that defeat the purpose? And if they are slightly different they each need to be tested separately. IMHO it is too trivial to bother having a global convenience impl of, but as I wrote on 1/20/03, feel free to file an RFE for the editor for int to handle tags with hints. Rochelle, let me know if the improvements to the integer editor Jesse suggets would do the trick for you, and if the endless parade of P1 and P2 bugs that is my existence slacks off for 24 hours I will implement it. BTW, int or Integer editor? - I could fix another enhancement request by replacing the int editor (should manage whitespace in setAsText reasonably - the default sun.beans... editor doesn't). Yes, that would help although I still have at least one place where I subclass the editor, so I'm not sure it would entirely solve the problem. I think the reason I do it is so I can show an invalid value with property marking even if the int is not in the list of constants, so if you can include that too, I'm set. While you're at it Tim, the JRE's boolean editor is not correctly I18N'd and you can't replace the strings "True" and "False" with e.g. "No jo" and "Ba ne". :-) I've tried a version of Jesse's solution and found a problem - I expected the tags to be in the order I supply them in the String[], but HashMap doesn't guarantee any such thing =). The old editor worked that way, so in implementing a new one, please keep that in mind. Working on replacement int and bool editors (the Integer and Boolean editors which wrap these will inherit their behavior). This will also allow me to solve issue 5278, the oldest issue I currently own. Created attachment 9227 [details]
Patch adding new hintable, internationalizable editors for primitive boolean and int types
Rochelle, please try out this patch and let me know if it meets your needs. The patch includes an update to the Explorer API documentation to document the new hints for int/Integer and boolean/Boolean types. To save you some trouble: For the Integer editor, you want to provide the following hints: String[] "stringKeys" - a set of keys you want the user to see int[] "intKeyValues" - the set of values corresponding to those keys Both arrays must be the same length and the length must be >= 1. For the Boolean editor (the only handling difference is case insensitivity), you can pass the following hint: String[] stringValues with the array ordered false, true (e.g. new String[] {"off","on"}). Let me know if this helps. I can commit it sometime next week if there are no problems (although it won't make it into 3.5 unless you find a way to make this issue a P2, I'm afraid). Re. patch: - suggest "intValues" not "intKeyValues" - behavior of javaInitializationString is debatable: if you are using e.g. constants like WindowConstants.EXIT_ON_CLOSE etc., then you want to use those actual strings: e.g. stringKeys={"EXIT_ON_CLOSE", ...}, intValues={WindowConstants.EXIT_ON_CLOSE, ...}, and you maybe also want some javaValues={"javax.swing.WindowConstants.EXIT_ON_CLOSE", ...} as well. If you are not setting source code constants, but just some random options e.g. for a SystemOption, then probably this method will never be called, but if it is then best is to use the raw number, as you do - BoolEditor.setAsText need not be so complicated - if you provide getTags then only those tags can be passed back to you. No need to check case, trimming, etc. - the user cannot enter freeform text. - don't forget that if applied this is a compatible API change -> needs apichanges.xml entry, spec version, note "since 4.whatever" in Explorer API HTML docs Created attachment 9332 [details]
Patch revised per Jesse's comments & including unit test
Revised patch attached. intKeyValues -> intValues Unit test included (had to do some monkeying with PropertyEnv - I assume there's nothing wrong with having a package org.openide.explorer.propertysheet in the core/test/src/unit? - I needed a way to get an instance of PropertyEnv). Docs patch revised. Jesse: I did keep the trimming in place in BoolEditor - though it would be dumb, someone could find some reason to call it programmatically for whatever reason. Added another hint, "codeValues" that allows initialization strings to be supplied. Also, attachEnv now sqawks loudly if it gets bogus values (like keys array longer than values array). I don't know much about these apichanges.xml docs - is there a walkthrough somewhere? Rochelle, do you want to review this or should I just commit it? I'm waiting for some word. Re. putting a package org.openide.explorer.propertysheet in a core unit test - this is not good I think. Use reflection if you need to. Re. trimming bool editor - no one should be calling PropertyEditor.setText programmatically, *especially* with bogus values. Leaving in such code will just mislead people into thinking this is normal. It's not and it need not be supported. "someone could find some reason to call it programmatically for whatever reason" - yes, they could, and when it fails to work and they whine on nbdev we will have the opportunity to ask them what they were thinking; this is a benefit. Re. apichanges.xml - http://openide.netbeans.org/versioning-policy.html and read the comments in the file itself which explain it. You *must* understand how to use this file and deal with API changes properly before working on API-sensitive areas of openide code. I haven't had time to actually look at the new patch itself, too busy, maybe ask someone else (Yarda?) for review if you are unsure. Tim, I think it makes sense to have someone else review it (Yarda, David S. or some other prop expert). I *do* intend to try it when I can, but since it won't be in 3.5 I had to put in my own version for now and I have some other high priority tasks to finish first. Hintable IntEditor/IntegerEditor committed to trunk, API docs updated. Rochelle, reopen if this does not satisfy your needs. IntEditor 1.1 I finally tried this and I'm getting the following exception (note that my constant *is* 8, but the number of strings and constants are both 3): Annotation: Exception in org.netbeans.beaninfo.editors.IntEditor Property Editor . java.lang.IllegalArgumentException: This property editor uses a set of keyed values, and the value 8 is out of range. at org.netbeans.beaninfo.editors.IntEditor.getStringRep(IntEditor.java:122) at org.netbeans.beaninfo.editors.IntEditor.getAsText(IntEditor.java:136) at org.openide.explorer.propertysheet.PropertyPanel.getPanelToolTipText(PropertyPanel.java:1380) at org.openide.explorer.propertysheet.PropertyPanel.setReadState(PropertyPanel.java:772) at org.openide.explorer.propertysheet.PropertyPanel$WriteComponentListener.prepareReadState(PropertyPanel.java:1735) at org.openide.explorer.propertysheet.PropertyPanel$WriteComponentListener.access$1300(PropertyPanel.java:1545) at org.openide.explorer.propertysheet.PropertyPanel$3.run(PropertyPanel.java:1706) at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:178) at java.awt.EventQueue.dispatchEvent(EventQueue.java:443) [catch] at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:191) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:144) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:138) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:130) at java.awt.EventDispatchThread.run(EventDispatchThread.java:98) My apologies, Rochelle - I made a truly dumb error and only tested the new code with a values array that was sequential and corresponded to the real values. I'll have it fixed by Monday. Sheepishly, Tim Fixed in trunk, IntEditor 1.4. Still not working =(. I get a slightly different stack with today's build: java.lang.ArrayIndexOutOfBoundsException at org.netbeans.beaninfo.editors.IntEditor.getValue(IntEditor.java:207) at org.netbeans.beaninfo.editors.IntEditor.getAsText(IntEditor.java:133) at org.openide.explorer.propertysheet.PropertyPanel.getPanelToolTipText(PropertyPanel.java:1380) at org.openide.explorer.propertysheet.PropertyPanel.setReadState(PropertyPanel.java:772) at org.openide.explorer.propertysheet.PropertyPanel.reset(PropertyPanel.java:722) at org.openide.explorer.propertysheet.PropertyPanel.<init>(PropertyPanel.java:285) at org.openide.explorer.propertysheet.PropertyPanel.<init>(PropertyPanel.java:290) at org.openide.explorer.propertysheet.PropertySheetTab.fillProperties(PropertySheetTab.java:290) at org.openide.explorer.propertysheet.PropertySheetTab.createPane(PropertySheetTab.java:238) at org.openide.explorer.propertysheet.PropertySheetTab.ensurePaneCreated(PropertySheetTab.java:193) ... Rochelle, could you attach the code you're using to produce this, or a simple test case? This is the code that's calling the exception: public Object getValue () { Integer v = (Integer) super.getValue(); if (values != null) { v = new Integer (values[v.intValue()]); } return v; } The way it works is, if keys and values are present, PropertyEditorSupport's getValue method is used to store the index into the values array; otherwise it is used to store the actual value. Is there any possibility for your property to return a value from its getValue method that is outside the range of the keys/values array? It *is* possible to initialize the editor with a bad value, before attachEnv() is ever called. I've sent it to you privately. Passing property editor issues to new owner, Jirka It's not planned for long time. It's fair to close as WONTFIX |