How should Java UI's be constructed?
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.
TSS misses the point
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.
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.
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
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
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.
Daniel Bryant, Arian Adair, Michael Hendricks Jul 31, 2015
A. Falck, M. Rezaei, E. Pederson, B. Brodie Jul 31, 2015