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();
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
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.
Okay! Here's some help.
You've joined the ranks of Mozilla Firebird, and Jetty, the Tads Virtual Machine by trying to make a new project with exactly the same name as an already existing, extremely popular project.
How about you rename it to something that isn't taken?
GINAC=>GINAC is not a computer algebra system
Step #1 of picking a name for any OSS is looking for it on Google.
Mod me down and I will become more powerful than you can possibly imagine!
A good GUI builder will allow you to mix and match between resource-based controls and code-built controls. Interface Builder on the Mac is a great example of this. I can use it to build extremely nice and functional windows, but when I run up against the wall of what it can do then I am free to mix in code for whatever is necessary. Normally the code I have to write is small, and put together the whole thing is vastly simpler than laying out everything in code just so I can get a little more power.
"I use a Mac because I'm just better than you are."
Take a look at the videos that demonstrate Netbeans 'Matisse' GUI builder. I use it all the time, and find it quite handy:
http://www.netbeans.org/kb/articles/matisse.html
Your design to a real part online: Big Blue Saw
IntelliJ's designer does exactly that. I saves the UI code in XML files and you only need to code the specific business logic in a seperate class. The designer itself is quite nice as well.
I have to say, I'm pretty impressed so far.
No thank you, what happens when they sell a couple of copies then go under. I am then stuck with some libraries I cannot modify or upgrade and a application that will have to then be redone from scratch. I don't care how fancy your wiz bang cool ui generator is, if I do not have the code it is definitely not going into my app.Right on their home page:
r c-1.1.zip
"BuoyBuilder(TM) is released as Open Source under the OSL license. Royalty-free, commercial licenses are available for purchase."
http://buoybuilder.com/DownloadData/BuoyBuilder-s
Want to improve your Karma? Instead of "Post Anonymously", try the "Post Humously" option.
I have played with XStream a bit. It's nice, but it has the disadvantage of (at least when I tried it) not being able to correctly serialize a Swing GUI. The Java Bean libraries are tweaked to understand Swing classes, so they correctly serialize the GUI in nearly all cases. (Minus a few of the fine details I was mentioning.) Deserialization is a minor issue in comparison.
I presume you mean the Swing classes? This can't happen with Java. The system stays backward compatible at all times, so it's practically guaranteed that your XML won't change from under you. The only time this is a concern is if you mix in third party components. In that case, you're sort of screwed whether you serialize to XML or not.
This is true, but it's again not a problem with Swing serialization. Unless Sun decides to reboot the Java platform. the Swing classes will remain compatible.
Again, not a problem with my approach. Since I did up the GUI in Netbeans, I could always modify the GUI and regenerate an XML file. The worst case scenario was that I'd need to tweak a few points in the XML after regen. It was a rather painless process.
If you need to add widgets or what-not, then you can always modify the GUI, and regen the XML. The really great part about decoupling with XML, though, is that it becomes really easy to just redo your GUI from scratch. Usually, if a GUI starts to look like a Redneck Christmas Tree, the cost of redoing it is unacceptable. (i.e. All the code is mixed in with the GUI layout.) When the GUI is decoupled, you can create a new GUI in the GUI Builder, and then serialize a new XML file to replace your old one. As long as the hooks into the GUI are the same (I used the "name" property), your code should operate without change.
If you're familiar with DHTML/AJAX, it's a bit like coding the HTML separate from the Javascript. Since the Javascript does a document.getElementByID(), you can recreate the HTML with a different look as long as the element ids remain the same.
Javascript + Nintendo DSi = DSiCade
If you haven't used Interface Builder (IB), then you are really missing out. Many people have a difficult time wrapping their brain around the concepts of Interface Builder, but I assure you it is across the board the best GUI builder paradigm yet invented. For a very brief introduction to its concepts, see Hold Me, Use Me, Free Me http://www.stepwise.com/Articles/Technical/HoldMe. html.
. htmlr Tools/Conceptual/IBTips/IBTips.html
In fact, IB should have been named "Object Connector" because it is not a "builder" at all. All IB does is let you instantiate objects, specify their initial state, and define connections or relationships between the objects. You should note that it is equally applicable to user interface objects and every other kind of object including your own custom classes. The configured objects are serialized to either a binary file or an XML file (your choice). The "Test" mode in IB just serializes and then de-serializes the object graph in memory to produce a fully functional system that you can test.
Although Interface Builder has been available since 1988, it is actively developed by Apple and is in fact free along with the rest of Apple's development tools with Mac OS X. Recent additions to Interface Builder have included Key-Value Observing which eliminates al lot of "controller" code from a system and Data Modeler which automates a lot of "model" code.
Steve Jobs used to state that it doesn't matter whether code is hand written or computer written, every line of code is a potential bug and a source for future maintenance. The only way to radically improve programmer and life-cycle productivity is to radically reduce the amount of new code needed to implement applications. IB is a stellar example of the wisdom oh his words. [This is also a huge win for cultural localization...)
Given the extremely rich frameworks of objects (both GUI and non-GUI) that are available from Cocoa, IB's ability to instantiate objects and form connections and relationships between them without any code is a huge win. If you haven't used this technique, trust me: you don't know what you are missing. You will never want to go back!
IB's down side has always been documenting (for posterity) all of the connections and relationships that are specified in IB. IB is improving on that front with XML file formats and data "entity-relationship" modeling built in. There have also been plug-in palettes that improve documentation generation.
Just as a reminder, unlike most GUI builders, IB works equally well with your custom classes and the framework classes. You can build new "palettes" for you objects to provide slick graphical interaction, but the basic connections and relationships capabilities work with all objects with no special effort.
Apple's IB description: http://developer.apple.com/tools/interfacebuilder
There is an excellent but shallow Introduction to Interface Builder at http://developer.apple.com/documentation/Develope
Speaking of GridBagLayout, this is the funniest animation I have ever seen...
http://madbean.com/anim/totallygridbag
Subversion can diff binaries, so it's not impossible. Also, as a sidenote, I remember a CLI tool that could read a NIB file and spit out a text file describing all its contents. This text file could be used to generate another nib file, so it was very useful when upgrading between incompatible versions of IB, and maybe it could be used to store release versions of NIB files in CVS.
Go hug some trees.