Skip to main content

JBeanEditor - are you interested?

2 replies [Last post]
Joined: 2006-11-26
Points: 0

Hi all,

I am sick of knocking up boilerplate GUIs to edit Javabeans-patterned objects. So I have written a - highly extendable - JPanel that automatically generates the fields at runtime using JXTable and J2SE's java.beans.* as the backend.

As far as I understand it, this was one of the original intentions of Javabeans, and it never materialised.

e.g. the following code

PropertyEditorManager.registerEditor(File.class, FilePropertyEditor.class);
PropertyEditorManager.registerEditor(Date.class, DatePropertyEditor.class);
Object bean = new Object() {
private File file;
private Boolean button;
private String name = "text";
private Date date;
JBeanEditor editor = new JBeanEditor();

will automatically generate a user interface like this (once you add it to a JFrame, etc)

I am still debugging a few aspects before I would be comfortable sharing the code (there are also some helpers for creating type-dependent editors).

I would like to know if this is something SwingX would like to include in future releases? (I've already signed the SUN contributor agreement when working on Netbeans).

Javadocs for the two main objects below (a typical use case doesn't need knowledge of the second object, BeanHelper, which is useful in its own right):

* An automatically-generated Swing Form for editing arbitrary objects
* matching the JavaBeans get/set pattern (properties) and optionally providing
* a {@link BeanInfo}.
* <p>
* This class was created in order to provide a light-weight editor to do a lot
* of boilerplate work in GUI design. Existing solutions require huge frameworks
* and are neither attractive nor intuitive to end users.
* <p>
* Editing of Javabean properties is supported at runtime through the programmatic
* provision of a suitable {@link PropertyEditor} to the {@link PropertyEditorManager},
* or - for a specific property - by setting the value to be returned by
* {@link PropertyDescriptor#createPropertyEditor(Object)} in the
* {@link BeanInfo}.
* <p>
* The {@link BeanInfo} is used for the following:
* <ul>
* <li>{@link BeanInfo#getIcon(int)} is displayed, if available.</li>
* <li>{@link PropertyDescriptor#isHidden()} is respected.</li>
* <li>{@link PropertyDescriptor#isExpert()} will produce a read-only entry
* (a useful interpretation of a vague API).</li>
* </ul>
* This is not capable of detecting changes made to the
* underlying bean by means other than the {@link BeanHelper} API,
* in which case a call to {@link #refresh()} is recommended.
* <ul>
* </ul>

* Abstracts the JavaBeans API providing sensible actions and accessors.
* Unless documented here, the JavaBeans API and surrounding ecosystem is
* ignored.
* <p>
* The following listeners are kept informed of changes made via the
* {@link Property} methods, but (unless manually managed) they will not
* be informed of changes through other means:
* <ul>
* <li>{@link PropertyChangeListener}s - added via
* {@link #addPropertyChangeListener(PropertyChangeListener)}
* - are informed after any change made here to the JavaBean's properties.</li>
* <li>{@link VetoableChangeListener}s - added via
* {@link #addVetoableChangeListener(VetoableChangeListener)}
* - are informed prior to any change made here to the JavaBean's properties.</li>
* </ul>
* Any other listeners are the business of the bean itself.
* @author Samuel Halliday

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Joined: 2006-06-08
Points: 0

Can you provide runnable code?


Joined: 2006-11-26
Points: 0

Sure! That's what I'm working on tidying up but hitting a few bugs here and there (see end of this message). Can I e-mail it to you initially?

There are about 6 classes at the moment:

- JBeanEditor
- BeanHelper
- PropertyEditorTableAdapter

and some "visual bean editor" implementations

- JPropertyEditor (abstract, base for the following)
- DatePropertyEditor
- FilePropertyEditor

I'd like to have Color and Image to complete a basic set. (They are trivial, just haven't gotten round to it)

1. I'm starting to think that a non-table implementation might have been a lot easier (and perhaps reliable across platforms) because it doesn't involve touching so much of JXTable (e.g. using GridBagLayout to create the columns and manage the row/column sizes).
2. J[X]Table has the concept of a "renderer" and an "editor" (which sadly don't share a common ancestry), but I'm only concerned with "editors". A fuller solution might try to have a registry for "renderers" allowing programmers to create obviously view-only bean properties (a read-only property in JBeanEditor will still have an "edit" button, but the changes are ignored).