Prompted by questions from an author of a Swing GUI design tool, lengthy debate was started on the topic of Java visual designers and resource based GUI's versus code generation on TSS and Slashdot. The TSS piece features the debate starting question of should a visually designed UI be binary / XML based or represented as generated Java code. The author argues that code generation is brittle and can lead to developers changing the UI in a manner which causes issues for the visual design tool. Sub-discussions also follow in the threads on of the use of visual designers vs. xml and separation of UI code from presentation logic which is often advocated for resuability and testing benefits. Visual and other alternative alternative UI construction methods have long been available for Swing and SWT while many would argue not at the level of Apple's Interface Builder or Visual Basic. Examples include:
Not all commenters were in favor of using a visual design tool or XML based DSL for UI construction. One TSS commenter had the following to say:
I have had a lot of experience with GUI work (including GASP!! Visual Basic). On my latest project though we have been building a GUI using Swing and the JGoodies libraries. The binding library supports Martin Fowler's Presentation Model. The Forms library has a nice layout manager called FormLayout that has a very simple descriptor language. I have to say after doing VB development I much prefer developing with these Java tools over the drag and drop method even VB provides. You have more control over your code and it produces very nice looking GUIs. I think it's even possible to develop more functional feature rich apps like this over anything a drag and drop or a xml describe method can provide.Before the project started we reviewed a couple of Java layout tools and none of them cut the mustard. The most common problems were: 1. They only handled the simpler problems GUIs tackle. 2. They couldn't handle odd user requirements. Like dissimilar object graphs that needed to be joined together into the same view or grabbing values that are only related to the object graph during the user's session. 3. Inefficient code was generated. 4. Aesthetically the screens didn't look nice and trying to tweak the descriptor (i.e. XML) language either wasn't possible to make it look nice or produced other undesirable effects.
