Gui Builders

[jh@schaubroeck.be]

Hi,

We are currently creating our first app with spring and therefor looking at rcp to build our gui. To facilitate the gui design process we want to use a gui builder (eyes on jformdesigner for now, see http://www.jformdesigner.com). I noticed that a view may be constructed with a gui builder, but a form is more difficult to integrate.

Say we create a nice form in a gui builder. How can we use this in our rcp app?
Normally a rcp builder does all the binding/intercepting/listeners/... stuff and places it on a panel, so I'm wondering how we can integrate/use our gui builder.

Kind Regards,
Jan

[Keith Donald]

Jan,

Spring rich is about simplification through abstraction: capturing common concerns typical of most Swing-based rich clients, and building them into the framework so they can be reused.

GUI builders take the opposite approach, in my experience. They are great for rapid prototyping, but spit out a ton of more low-level code that isn't organized in a way that can be reused (from outside the confines of the builder tool.) They also tend to work with strange layout managers--like SpringLayout (no pun intended!), which are nightmares to use by hand.

So in general, Spring rich favors component factories for consistent component creation, and layout builders that make building forms easy by hand. It would be possible to build a tool atop our factories/builders, but that is certainly not in our scope (and we're not to the point maturity wise where tools vendors would be doing that.)

One possible approach would be to rapdily prototype a form, paste that into a ControlFactory's "createControl" method (most spring rich client objects like forms and views are ControlFactories), and tweak it. So with this hybrid approach, the GUI builder would provide a jumpstart to creating the form, which you could then take, plug into our framework, and clean up as much as you feel the need to.

[oliverhutchison]

Jan,

Just to reiterate what Keith has already stated; while form builders are good for prototyping, the code they generate by can become extremely hard to maintain a couple of years down the track.

I'm speaking from experience - part of my job is to maintain a large number of legacy forms that were created using the NetBeans GUI builder about 3 years ago. Day to day I use Eclipse and only switch over to NetBeans if I need to tweak a form, however what often happens is that the formatting from Eclipse is incompatible with what the NetBeans GUI builder expects so it chokes and is unable to do any updates to the form. When this happens I have to pull an old version of the form from CVS, patch the formatting back to what NetBeans expects, update the form etc. Now this can be a lot of work when all you need to do is add a single text field or change the alignment of a label!

Obviously things might be better with jFormDesigner but I strongly recommend that you give the form builders the ship with Spring Rich a try out. IMO the form builders are one of Spring Rich's killer features. I can't imagine a simpler way to define a form than this!



TableFormBuilder formBuilder = new TableFormBuilder(formModel);

formBuilder.addSeparator("Name");
formBuilder.row();
formBuilder.add("title");
formBuilder.add("firstName");
formBuilder.add("lastName");
formBuilder.row();
formBuilder.addSeparator("Address");
formBuilder.row();
formBuilder.add("address1");
formBuilder.row();
formBuilder.add("address2");
formBuilder.row();
formBuilder.add("city");
formBuilder.add("postcode", "colSpec=2cm");
formBuilder.row();
formBuilder.add("state");
formBuilder.row();
formBuilder.add("country");

return formBuilder.getForm();



Ollie

[jh@schaubroeck.be]

Thanks Keith & Oliver,

We'll probably use a guibuilder for prototyping and just see if we can use some parts (JFormDesigner supports JGoodies Form Layout and has some custom code generation stuff, so maybe there can be some starting point...)

I'm a bit confused: there's AbstractFormBuilder and FormBuilder, each in a different package. They don't have any relation to one another? And then there's also JGoodiesBeanFormBuilder and JGoodiesFormBuilder outside the builder package (along with FormBuilder). Are they misplaced?

I think I'll give the TableFormBuilder a try instead of the JGoodiesBeanFormBuilder. Another posting pointed out that the former is more robust, is that correct?

Kind Regards,

Jan

[Keith Donald]

Yes, favor TableLayoutBuilder and the GridBagLayoutBuilders.

We are still in the process of organization of the form package, and related subpackags like form.builder. Stuff in "forms" will be being moved over to form and/or removed all together (much of that code is older, from when I was trying to show a quick proof of concept!)

SwingFormModel will also likely be changing to FormComponentFactory, accepting a FormModel interface. I don't like how currently we have to pass around SwingFormModel implementations everywhere.

[joecole]

Hi,

I would like to make some comments on the automatic ui layer generation. My company has implemented 5 ?aui? engines for our product line over the last 3 years (3 for swing, 1 for j2me and 1 for superwaba) so we have lots of experience in this space.

1. Provide default implementations that do not rely on beans. Relying on beans means you have to use beans [obviously] which is a rather horrible design (according to some). We track raw fields via reflection. We have used this technique in a production project with over 800 hierarchically structured data fields (genetic analysis).

2. Provide default implementations that do not require hand-coding the implementation of the gui. For example, the code:

"TableFormBuilder formBuilder = new TableFormBuilder(formModel);

formBuilder.addSeparator("Name");
formBuilder.row();
formBuilder.add("title");

etc etc"

may not need to be implemented this way.

Our code, while not as flexible as the above, uses a single line to produce a bound form based on a form model. I see no reason why this could not be implemented at an abstraction level above the code above.

3. Hard-coding ui row /col information in the way above ties you to a single implementation. In our engine we have many types of form builders, each implementing a simple interface similar to the one below from memory:

interface FormViewBuilder {
void addSeparator(String separator);
void add(String label, JComponent component, String example);
}

We can switch between many different types of form builders (1-4 columns, questionnaire type, boxed, unboxed, tabbed etc). We have validation form builders and also wizard builders also which enable us to have complex logic applied in a single line.

I have tons more comments if youd like it. Just email me privately. We could even open source it if someone wants to take up the work of refactoring - we dont have time.

Joe Cole

[Keith Donald]

Joe,

Thanks for your comments.

Just to address a few real quick, our "PropertyAccessStrategy" is pluggable: a bean based access strategy is just our primary implementation--it's possible to extend to support generic collections, rowsets, or other data structures. We share a similiar vision with JDNC in this regard.

I have difficulty following your second point--perhaps if you elaborate with an example of what you mean by "an abstraction level above the code."

We have several different types of builders delegating to different layout managers (form layout, grid bag layout, etc.) These builders also delegate to pluggable factories for control creation, so you do have some ability to configure what a given builder produces. I'd be interested in seeing your code to learn more about your approach, though, certainly.

Keith

[joecole]

Point 2:

For example, here is an excerpt from the code (from memory, its been a while):

ViewFactory factory = ...

View view = factory.create(model);

view.show(); // for dialogs, frames, wizards or property boxes

The point was to automatically bind each field in the model according to smart defaults. So it takes a single line to create each view instead of hard coding the construction.

Another thing our code did was automatically handle hierarchies. For example the model:

class A {
String label = "default";
B b = new B();
}

class B{
int x = 100;
Collection objects = new Collection();
public B(){
objects.add(new PrototypeObject());
}
}

This would produce a dialog with the following layout (without any customisation):

A // title
Setup A // description

Label [default] // textfield
B [Setup B] // button

save cancel

When "Setup B" was clicked another dialog (or page or whatever) would be shown with the fields in B. When the collection is clicked in page B, a table or list would be shown with all the fields in the prototype... etc etc etc.

The general structure of our package is very like the design of xstream. We had "binders", "adapters" and "constructors" for each type of data (String,int, etc etc etc). When a model was passed to the view factory, our code simply iterated all fields, determined the individual field type, contructed the appropriate component, added the appropriate listeners, adapted the default value to the fields value, and bound the field [bi-directional] to the component created for it.

Originally we had planned on commercialising it but never got around to it due to other projects going better than expected.

Contact me if youd like more info.

Also - if you share a similar vision to jdnc, why not contribute to it instead of build your own? The main reason I can think of is product branding - i.e. leveraging off springs success?

[Keith Donald]

Re: JDNC--we are pursuing integration with their community, and we want to continue down that path. I have contacted Amy Fowler and lookup forward to working more with them.

We exist for several reasons. One, we existed before JDNC, and we all know how choices on the desktop (particularly good application frameworks) have been sparse to come by. While things are certainly changing now, this area is not exactly mature, and in an immature market it's good to have competing solutions to foster innovation. Secondly, we only overlap in parts, and will never focus on some parts JDNC does. For example, we are NOT a component provider. We are not going to roll our own XML markup language.

In general, Spring Rich is at a higher-layer than the components, shipping with abstractions that wield the underlying widgets, capaturing common J2EE rich client concerns in a reusable form. So all our application management stuff, our dialog and wizard support, our command framework, our databinding and validation framework, all exist at a higher-level than the components. Hence, we view a prime integration opportunity with JDNC's snazzy J* extensions. Just like we view integration with JIDE docking and view actions as very important for enhancing our platform with an awesome L&F. But it's about choice--Spring rich, like Spring is "all about choice."

Re: your point #2---one question: what do you mean by "sensible defaults?" I assume you mean metadata about the "model" to be used to drive default generation of the view? Yes, metadata driven control selection and auto-form creation is important, but I also find many users want control over their GUI layouts. We need both approaches.

Keith