Alex Konshin wrote:if such standard would be implemented in WindowBuilder and Eclipse 4 (e4) then it has a good chance to become a de-facto standard.
It's not the place for WB to implement any new APIs like that. I don't see such a standard emerging from Eclipse either (for example, I don't see any significant adoption of XWT by Eclipse.org projects).
Alex Konshin wrote:One of the obvious benefit is separation of code from meta data as UI declaration actually is.
I view GUI classes as being first class components of an app just like the data model (subject to refactoring, inheritance, etc.). While the UI might be considered meta data in some apps, I don't see that being the general case. If your UI is truly data driven, then there isn't much of a need for a GUI builder, and you probably aren't even using Java to define your data model.
Alex Konshin wrote:It also would simplify splitting tasks between developers (one could be responsible for representation UI while another implement business logic). Well, you might say that it can be done now by changing Java code but please note that any changes in Java code lead to reintegration, retesting and redeploying of the application. But in fact you just changed meta-data. If, for example, your UI is driven by data structure than it doesn't make sense to rebuild application if that structure is changed.
Again, if your UI is driven that way, you might as well just have your UI generate itself dynamically and dispense with the GUI builder entirely. I also don't buy the argument that it will simplify splitting of any tasks...or at least I have never seen this done successfully. In most apps, it is very likely that any change to UI will require changes to the application logic as well. In that case, there is a lot of benefit to having the UI and the app logic all written in the same language and supported by the same tools (like the Eclipse JDT).
Alex Konshin wrote:Another benefit would be unifying usage of Swing and XWT in Java code. Theoretically I don't see any problem for GWT to join this list. If all forms would be loaded from XML and bindings are established the same way for all these frameworks then Java code might be the same. As result this feature might really make Java GUI application become "write once run anywhere".
I've seen lots of XML-based UI APIs, and they all suffer from the least-common-denominator problem. SWT, Swing and especially GWT have some significant differences that would be difficult for any XML API to capture. Defining your Java application UI in Java means that you have the full power of Java available to you. Defining your app UI in XML limits you to the subset of UIs that the XML API is capable of supporting (which is often quite limited).