Slashdot Mirror
Resource-Based GUIs Vs. Code Generators In Java
Java Fan writes, "There is a good debate about GUI generation tools for Java going on at theserverside.com: 'Almost every platform has a visual designer that serializes the GUI to resources (some XML, some proprietary binaries) and then attaches it to the controller at runtime. Apple has had this for years with Interface Builder, Vista has a similar philosophy now as well. Java developers though are left with either hand coding of GUIs or potentially messy and brittle code generators. Neither of which promote good MVC separation. In fact they tend to encourage violations unless you are a very disciplined coder.' Personally, I am partial to BuoyBuilder as a great solution to this issue."
300 bucks for a crappy UI builder that adds multiple layers of abstraction on top of Swing! That sure is cheaper than Visual C# Express, Interface Builder, SharpDevelop, wxWindows, Visual Basic, or any of the GUI builders available for Eclipse!
Wait, no, sorry. It's not.
Nice slashvertisement.
using namespace slashdot;
troll::post();
In theory, I'm not against the use of a GUI builder as long as it provides a way to use all of the layout managers that are available. I've just never seen one that could scale in complexity to the needs of a real world application. Sooner or later, the functionality requirements drive GUI elements to be created based on configuration settings and/or business rules. That is where you hit the wall with the GUI builder.
Anyone who's interested in this issue should look into the java.bean.XMLEncoder and java.bean.XMLDecoder classes. These classes are able to serialize and deserialize complete GUIs. In the past, I've used the Netbeans GUI Builder to develop throw-away GUI frontends, then serialized them to a file rather than using them directly. I then built a framework that used the little-known "Name" property on AWT/Swing components to attach actions.
The results were quite good. Not only was the GUI decoupled from the code, but development was actually accelerated as minor GUI hiccups had no effect on the rest of the codebase. The downside was that the XML occasionally had to be tweaked to perfection as the XMLEncoder class was not 100% perfect in serializing some of the finer details.
A few years ago I spoke with one of the Netbeans developers about making the XMLEncoder format the standard for Netbeans. The idea was met with some resistence, seemingly because there was no actual Java-standard framework to target. The JVM base libraries have the Encoder/Decoder routines, but all the rest of the work must be done by the programmer. (Such as attaching the actions to the components.)
Train yourself to use Swing Actions. It seems like you're creating hundreds of little objects, but what you're really doing is encapsulating actual actions in the system away from their physcial controls on screen. So if you have a button, a menu item, and a toolbar item that all do the same thing, a single action can control all three widgets. This helps smooth out issues like keyboard shortcuts, which can get quite confusing when coding a Swing application.
Javascript + Nintendo DSi = DSiCade
We started a project along the lines of Interface Builder with a Java Swing implementation for our master's thesis in 2005. It's called GINAC, as in GUI Is Not Application Code.
As I really hate designing GUI's in code, I've started working on it again lately, currently implementing something along the lines of cocoa bindings. If anybody is interested in helping out, let me know!
I'm not sure how they released without some sort of GUI building tool. I haven't used Java in awhile, but I remember coming up with Shakespearean-esque curses to describe what I thought of GridLayout and their buddies.
Is there an accepted good builder now? The article seems to imply this is far from a solved problem. (10 years later!)
..don't panic
Possibly Java's greatest strategic feature is the classloader that can dynamically retrieve classes across the network at runtime and safely instantiate them. If Java had a standard API and data format for de/serializing UIs that accommodated their remote contexts, applets could become much smaller and dynamically bound to the UI facilities of their arbitrary runtime platforms. If these mobile UIs were componentized with a consistent internal API, applets could share UI elements among themselves on the same host. That architecture would not only reduce distribution size and increase flexibility, but it would promote reuse of the same UI components across applets, increasing user productivity with fewer learning curves.
If those APIs don't already exist, reusing an existing one, especially Flash, would offer possibilities for reusing existing components or patterns already populating the Net.
Java could increase its stature among distributed architectures. And make our lives easier.
--
make install -not war
Java developers though are left with either hand coding of GUIs or potentially messy and brittle code generators.
Whenever it comes to Java it always amazes me how many people have very outspoken opinions about it while its almost immediatly obvious that they hardly know what they're talking about. Then again, when reading the article its becoming obvious that when he's talking about GUI's (since when do you code in a GUI? I use an IDE for that) he actually means to say Eclipse. Don't get me wrong: I'm not dissing Eclipse here, but do question his bias.
When it comes to building GUI's Java really allows itself to be used by code generators IMO simply because Java is very modulair build. The only problem you might face here are the somewhat limited layout managers. For the non-Java people amongst us: these basicly define the "interface" between the GUI you're building and the way it behaves. For example; when it comes to resizing or placing of the objects then you're dealing with a layout manager.
Now... When it comes to Java IDE's two names immediatly spring out: NetBeans (my personal favorite) and Eclipse. Now that he has commented on the latter let me comment on the first. From NetBeans 5.0 and up it comes with a fancy GUI builder codenamed "Project Matisse". Its official name is now NetBeans Swing GUI builder. After taking a closer look at that I wonder if he still thinks that there are no decent GUI builders available for Java.
The real problem here isn't so much the GUI builder but the underlying layout manager which needs to keep things in check. I think that also explains why there isn't much of this available as it looks to me as if there aren't many people about who manage to come up with decent Java coded tools which can be used and adopted by many other coders. NetBeans has solved all this by introducing a layout manager of their own, the so called Absolute Layout. Pro's are its extreme extensiveness, the con's are that if you wish to use it you'll have to ship it with your software because its not part of the standard Java Runtime Environment (JRE).
If you wish to see a demo of Matisse in action then check out the NetBeans flash demos, especially the first part of "Why NetBeans?". Personally I'd recommend another approach, namely simply downloading NetBeans and trying it out for yourself. Its available for Linux, Solaris, Windows and I think even OS X.
The Java-Gnome Project uses Glade to build a serializable (to XML) GUI.
Neither of which promote good MVC separation. In fact they tend to encourage violations unless you are a very disciplined coder.
I don't mean to sound all high and mighty, but if you aren't a disciplined coder, then you're not very serious anyway. You can pre-plan the MVC design to your hearts content, but it takes discipline to stay within the boundaries of the original design. Especially since if you don't then you create one of the worst anti-patterns ever, making you wish you'd just written one monolithic chunk of procedural code because bugs/changes would be doable.