Custom Property Editor code generation

Swing Designer allows you to quickly create the frames, panels, dialogs, applets and other UI elements that comprise Java Swing applications.

Moderators: Konstantin.Scheglov, gnebling, Alexander.Mitin, jwren, Eric Clayberg

Custom Property Editor code generation

Postby murat_ar » Mon Jun 21, 2010 12:14 am

I have a custom property editor, which generates java code smoothly, with Window Builder 6.9.4. But the same custom property editor does not generate the code with WindowBuider 7.4. It looks like Window Builder 7.X's calling order of PropertyEditorSupport's methods is different.

Window Builder 7.4 calling order (??):
- PropertyEditorSupport class cons()
- supportsCustomEditor()
- getTags()
- setValue()
- getAsText)
-getCustomEditor()
- setValue()
- getAsText)
- getJavaInitializationString()
- setValue()
- getAsText)
..... never calls getValue()

Window Builder 6.9.5 calling order (??):
- PropertyEditorSupport class cons()
- setValue()
- supportsCustomEditor()
- setValue()
- getAsText)
- supportsCustomEditor()
- getCustomEditor()
- getValue()
- getTags()
- setValue()
- getJavaInitializationString()
- setValue()
....

Do you have a document for Custom Property Editor implementation (especially the order of method calls)
murat_ar
 
Posts: 5
Joined: Tue Jun 01, 2010 4:16 am

Re: Custom Property Editor code generation

Postby Eric Clayberg » Sat Jun 26, 2010 5:50 am

We could not find any official docs on the PropertyEditorSupport life cycle, so we believe that any reasonable sequence can be used. There is also no requirement that we call getValue() at any specific point (currently, we call it after getJavaInitializationString()). Those two methods are distinct and should not depend on each other. If your property editor requires getValue() to be called at a specific point, then you should do that internally to your custom property editor. For example, if your implementation of getJavaInitializationString() requires that getValue() be called first, then you should put that call into your getJavaInitializationString() code. You should certainly not assume any specific life cycle because it will likely be different for different tools. Swing Designer v6.9.x and v7.x use different sequences because they are entirely different implementations. As a convenience for you, we have moved our call to getValue() prior to the call to getJavaInitializationString() in the latest Swing Designer v7.6 build.
Eric Clayberg
Software Engineering Manager
Google
http://code.google.com/webtoolkit/download.html

Author: "Eclipse Plug-ins"
http://www.qualityeclipse.com
Eric Clayberg
Moderator
 
Posts: 4503
Joined: Tue Sep 30, 2003 6:39 am
Location: Boston, MA USA

Re: Custom Property Editor code generation

Postby murat_ar » Mon Jun 28, 2010 1:44 am

Thanks for the answer. But I think you'd better document and publish the PropertyEditorSupport life cycle of your tools.
murat_ar
 
Posts: 5
Joined: Tue Jun 01, 2010 4:16 am

Re: Custom Property Editor code generation

Postby Eric Clayberg » Mon Jun 28, 2010 8:20 am

The life cycle is subject to change at any time, and you should rely solely on the JavaBean spec itself for that info. As long as your editor complies with the JavaBean spec (and does not make any assumptions not supported by that spec), it should work fine. You should not code it for a specific life cycle as that can be different for different tools and can even change within a given tool. Your original problem sounds like you were expecting getValue() to be called as a precondition for getJavaInitializationString(). Nothing in the spec indicates that will be the case. In fact, both of those methods are independent of one another and should be callable in any order.

That said, the following is the current life cycle we are using. As said above, this is subject to change at any time.

1. Initialization.
1.1. Call java.beans.PropertyEditor.supportsCustomEditor() to check if it has custom AWT component used for editing, which we show in dialog after clicking "..." button.
1.2. Call java.beans.PropertyEditor.getTags() to check if property value must be one of a set of known tagged values. In this case we create combo-box based editor.
1.3. If no tags, then editor is text based.
1.4. Before calling any PropertyEditor method, always check if it has java.beans.PropertyEditorSupport.setSource(Object) and call this method with value of toolkit object.

2. Painting.
2.1. In any case call java.beans.PropertyEditor.setValue(Object).
2.2. If java.beans.PropertyEditor.isPaintable() then use java.beans.PropertyEditor.paintValue(Graphics, Rectangle)
2.3. In other case call java.beans.PropertyEditor.getAsText() and paint this text.

3. Editing.

3.1. Text based editor.
3.1.1. To get text to edit call java.beans.PropertyEditor.setValue(Object) then java.beans.PropertyEditor.getAsText().
3.1.2. To set text after editing call java.beans.PropertyEditor.setAsText(String), then to get Java source call java.beans.PropertyEditor.getValue() and java.beans.PropertyEditor.getJavaInitializationString().
3.2. Tags based editor.
3.2.1. When user drops-down combo-box, call java.beans.PropertyEditor.getTags().
3.2.2. After item selection do same as for text-based editor - use setAsText(String), see 3.1.2.
3.3. Custom component editor.
3.3.1. When user clicks "..." ask for editor java.beans.PropertyEditor.getCustomEditor() and show it in modal dialog.
3.3.2. If user closes dialog using OK, use current java.beans.PropertyEditor value, so call java.beans.PropertyEditor.getValue() and java.beans.PropertyEditor.getJavaInitializationString().
Eric Clayberg
Software Engineering Manager
Google
http://code.google.com/webtoolkit/download.html

Author: "Eclipse Plug-ins"
http://www.qualityeclipse.com
Eric Clayberg
Moderator
 
Posts: 4503
Joined: Tue Sep 30, 2003 6:39 am
Location: Boston, MA USA


Return to Swing Designer

Who is online

Users browsing this forum: No registered users and 1 guest