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.
/filters:no_upscale()/sponsorship/topic/f0678c4e-297d-4505-bee4-d3599940528c/QConLogoRSB-1637822228684.png)
/articles/java-jvm-trends-2021/en/smallimage/InfoQ-Trend-Report-logo-1641794256028.jpeg){kind=logo}
/presentations/java-fast-release-cadence/en/smallimage/qcon-plus-s-1640192096828.jpg)
/articles/six-features-jdk12-to-jdk17/en/smallimage/six-features-from-Java-12-to-17-to-get-excited-about-small-1639487914685.jpg)
/presentations/java-update-versions/en/smallimage/Marc_Hoffmann-s-1637581262221.jpg)
/presentations/java-16-17-future/en/smallimage/PAN(2)-1632150528562.jpg)
/articles/why-how-upgrade-java17/en/smallimage/upgrade-to-java-16-or-17-small-image-1630333858357.jpg)
/articles/java-16-new-features/en/smallimage/what-is-new-java-16-small-image-1628078662649.jpg)
/minibooks/building-microservices-in-java/en/smallimage/logo-1628016827482.jpg){kind=logo}
/articles/java-external-rules-engine/en/smallimage/logo-1637682106961.jpg){kind=logo}
/articles/introducing-kivakit/en/smallimage/logo-1637780334611.jpg){kind=logo}
/presentations/resilience-supply-chain-security/en/smallimage/Dan Lorenc-s-1643295247721.jpg)
/presentations/observability-understandability/en/smallimage/observability-understandability-s-1643301909913.jpg)
/articles/financial-times-engineering-enablement/en/smallimage/enabling-engineering-productivity-at-the-financial-times-small-1643105626728.jpg)
/presentations/scale-cloud-native-apps/en/smallimage/infoq-live-logo-s-1643293439025.jpg){kind=logo}
/articles/colors-dotnet-guide/en/smallimage/logo-1643054532698.jpg){kind=logo}
/articles/hybrid-remote-2022/en/smallimage/logo-1642153435805.jpg){kind=logo}
/articles/beyond-monitoring-change-intelligence/en/smallimage/logo-1642766732099.jpg){kind=logo}
/presentations/adopting-service-mesh/en/smallimage/christian-posta-s-1642498124139.jpg)
/presentations/facebook-quic-http3/en/smallimage/facebook-quic-http3-s-1642498804884.jpg)
/presentations/kotlin-frameworks/en/smallimage/justin-lee-s-1642498214054.jpg)
Community comments
TSS misses the point
by Jonathan Allen,
Helper libraries
by Rickard Öberg,
It is about quality
by Robert McIntosh,
Spring Rich Client
by Benoit Xhenseval,
TSS misses the point
by Jonathan Allen,
Your message is awaiting moderation. Thank you for participating in the discussion.
I think the problem is Java is too fixated on patterns without having the understanding of why they exist. The MVC pattern is a way to write Smalltalk GUIs, not a goal in and of itself.
Now I'm not saying that seperating the Model from the rest of the control is bad, in fact it can be quite helpful. But the idea that you can seperate the View and Controller in such as a way that each can be reused independantly is stupid, and the original MVC white paper says so.
The Java community needs to step back and ask, "How do I make a good GUI or web toolkit?" As long as they are still asking "How do I encourage people to use the __ pattern?", things will continue to suck.
Helper libraries
by Rickard Öberg,
Your message is awaiting moderation. Thank you for participating in the discussion.
We do lots of dialog oriented UI's and have had to work quite hard to distill our coding style down to a very condensed format where we can express both UI and model bindings on one line of code (usually). This sets up the UI component, binds it to the model, and expresses what resource bundle properties to use for labels. It can also be combined with other helpers to do more advanced things like enable/disable panels based on checkboxes and things like that. We are using JGoodies FormBuilder as the main building block, and that alone saves a lot of work because of its solid and easy-to-work-with layouting.
Here's a typical example of how we set up a label+textfield and bind it to a JavaBean property:
builder.appendLine("theLabel", connector.connect("someField", new JTextField()));
The builder has a ResourceBundle associated, which it will use for finding "theLabel". The "connector" sets up property change listeners on a target Java object and also registers listeners with the provided component (a JTextField in this case). "connect" returns the components which allows for the condensed coding style, and also allows for chaining things (like "enable this field if that checkbox is checked) to it before adding it to the dialog.
With this in place I can do simple things easily and I still can do advanced things if I need to, without touching an XML file or generated code.
It is about quality
by Robert McIntosh,
Your message is awaiting moderation. Thank you for participating in the discussion.
I worked for two companies where we built Swing GUIs and in the second company the president was very fond of UI builders (in this case visual age). For me it all comes to down to quality code and readability. Builders tend to be too fragile and too rigid, and in the long run don't always end up being quicker to develop. Other techniques like XML descriptions and such also tend to fit into this category.
I suppose however they will always be popular, just like most ORM tools will be. If you don't mind being forced into their way of doing it, they have value.
I agree with Rickard that the real benefits come from helper libraries that provide help when you want it and only when you want it.
Spring Rich Client
by Benoit Xhenseval,
Your message is awaiting moderation. Thank you for participating in the discussion.
I would like to mention Spring Rich Client, a project that has been around for a couple of years in the periphery of Spring (spring-rich-c.sourceforge.net/).
To me it is definitely a step in the right direction as it can take an object, create a model from it and create a form like builder.add("propertyName") and, via some XML, it is i18n-ed, it has type-specific binders, property-specific binders (it will recognise a date for instance or a percentage).
Validation rules can be created and the form cannot be committed before, only on commit would your object actually be modified so it is a doddle to implement cancel/revert etc...
I'm not a SpringRC developer by the way, just a happy user.
Learning curve is steep though...
I think it should be mentioned.
Benoit