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."
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.
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
Cost is irrelevant. Quality is the only measure.
That's the ivory tower answer, and from a certain perspective it's true and from a certain perspective it's not.
The last Java shop I worked in wouldn't pay for any development tools. Good tools that were free (as in beer) or close to it were at a premium.
XML-based Swing GUI tools are really a dime a dozen, and always seem to add an extra layer of complexity to Swing-based apps. Swing is a really nice component system, and pretty much every object is easily extendable. Personally, I have tried a good deal of the XML-based systems, and really using Swing as it was intended is the way to go. Build your own components, extend them, combine them. I know that there is this idea that you hand over the frontend to a designer, but we all know that most of the time it is the developer hacking on the frontend.
I can understand why people think they need XML-based systems. So much Swing-based code sucks ass. Putting all of your buttons and frames in a big-ass method is nasty and hard to maintain. Well-thought-out componentized Swing code is easy to maintain and nice to look at. Plus, once you are finished with your project, you can re-use any components you built. Swing is a great library - more people need to just learn it.
I use XStream which is very nice xml serialization utility library. XStream has very nice aliasing abilities, so you can trim the xml to very close to absolute minimum ( 2 minute tutorial).
Currently I'm planning on externalizing website validation objects as xml so they can be updated more easily and dynamically. It's basically the same thing you describe and I can easily see how it would help with GUI programming. To get around the "attaching actions to the components" problem you can use the MVC design pattern. Set the gui elements to return an event id and use a central controller class to send the event flow to the proper commands.
The XML-serialization has a few problems though:
Anyways, XSLT can be used to convert older XML formats to new format and XStream's aliasing functions helps, but you still have to be careful when making changes.
I'm not sure why Java GUI's being behind the curve and difficult to work with is news. Anyone who has actually used the word 'Gridbag' knows that Java GUI development is a process somewhat akin to Chinese water torture.
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.
Java already has external XML GUI description files. They are the .form files generated by Matisse. Matisse lets me drag and drop together a GUI just like any other drag and drop program. It's not brittle; it's rock-solid, fast, and it makes the best-looking forms I've ever seen. At this point I would prefer to build a Swing app over a Web app, because Matisse makes the Swing app so much easier to build and make it look good.
The one problem with Swing is it is capable of doing too much, which makes some of the simple stuff more complicated than it should be. But I can do any kind of visual effect I want to do. Spend a week or two using Matisse and then decide what you think about Swing.