« Groovy vs. Cocoa: invoking a method on the main GUI thread | Main | Groovy can save Swing »

Declarative GUIs in Java, Lysol for Code Smells

One of the complaints about Java Swing GUIs is not really about the platform per say. but is actually more about the tooling, standard or otherwise. The major lacking feature is a widely deployed declarative format for Declarative GUIs. This is pointed out quite clearly by one develper who left Java to code Cocoa apps.

It's not that there is a lack of a good GUI Design Tool. I could rave for days on end about NetBeans' Matisse builder and the new Group Layout. It provides for me a good balance between efficient visual layout and the ability to get into the code to tweak at it. The solution, guarded and non editable code blocks, was derided by Elliotte Rusty Harold as a code smell. I kind of have to agree with him.

So how do other platforms handle it? The C# portion of Visual Studio 2005 uses a new feature of C# called Partial Classes, basically it allows you to declare a class in two files. In the main file goes all of the user editable code and in a parallel file goes all the code that the GUI designer will smash, basically all the code that can go away after a billg or sjobs encounter.

Cocoa uses a different approach: via ".nib" files. These are generated by the Interface Builder tool that is a standard part of XCode or it's predecessor since, gosh, 1988. Yes, it's older than the GPL. So these ideas aren't exactly revolutionary or cutting edge.

The silly thing is, there is very little stopping NetBeans from adopting one of those two approaches, private access fields and methods not withstanding. They have an external data file (the .form file) that could either be read and executed dynamically (if needed fields are made public or it is granted privilege escalation to change access levels via reflection) or compiled to a parallel Foo$$Form.class file.

Such a declarative appeared last year on the roadmap, but the living document version has no such mention of it. What happened? Was this a reference to JDNC? I hope not, because JDNC is now defunct.

So, NetBeans Form team, any new guidance on the issue?

Comments (4)

Danno Ferrin [TypeKey Profile Page]:

F3 lacks a WYSIWYG GUI designer. What I am looking for is the NetBeans GUI designer to not reach into my code (as much) yet still work.

Have you seen XUI?

The NetBeans editor separates the the UI from the code see:

Version 3.0 (due in March) also provides an Eclipse plug-in

Danno Ferrin [TypeKey Profile Page]:

The problem I have with all toolsets that try to abstract away Web and Desktop Client differences is that all desktop apps feel like web pages. You develop "pages" not frames and dialogs. It would be similarly silly to design a web page around frames, dialogs, and discrete JComponents.

Noble idea, but the abstractions leak way to much. I don't want to sacrifice the power of a desktop app so that it can be designed like a web page.

Post a comment


This page contains a single entry from the blog posted on February 14, 2007 8:50 PM.

The previous post in this blog was Groovy vs. Cocoa: invoking a method on the main GUI thread.

The next post in this blog is Groovy can save Swing.

Many more can be found on the main index page or by looking through the archives.

Powered by
Movable Type 3.33