Hi, I once again don't know if this is the right channel. I hope to
start some discussion, and maybe this belongs into bugzilla.
I'm currently doing some investigations on state of the art ui
development. In my own project I choose RCP for many reasons. This is
why I post here today..
The general state of the universe seems to me like we are still
experimenting in many areas. I've been so happy with the arrival of
databinding, but it still needs a lot of coding.
I stumbled across gooey
https://aptframework.dev.java.net/gooey/gooeyController.html
they have some interesting ideas. For e.g.
automtic binding by convention (perhaps overidden by annotations)
they suggest to have some mechanisms like
@Event void ok() {
to implement a listener for a button thats named okButton.
and some other nice ideas. Wether this plain java approach is a good
idea or if there are better ways - I will leave that to be discussed.
I'm not solving the puzzle (at least not by now :) but I agree with many
voices that coding ui's by current api's is sometimes comlicated and ugly.
I can see two approaches:
Markup (Xaml?) and DSLs (JavaFX, glimmer etc)
the problem I see with markup is that its great for building tools
around, but it's getting bad when you need bridges to code (With
Microsoft blend beeing nice, a so called UI Designer still has to know
method names and blend doesnt help him thereby afaics) XUL has been
araound a while but I don't know anyone who uses it.
The web guys come up with EL there and once again you have some kind of
code in your view definition. I would prefer to see a button, and the
magic behind the button (its behaviour) should be defined in a
controller. Even if you disagree and allow some code in the view
definition, it still hard to validate and refactor. The problem with
markup is, that its hard to reference from code, and even if you do that
(by id conventions, by xpath or something else) it strikes you when you
want to refactor somehing.
I tend to like the dsl approach more, as it can be compiled, maybe it
can be typesafe and have tight java integration. And it would be even
better if we had cross language refactoring tools. the glimmer approach
implies groovy, and maybe I didnt understand it right, but I think its
still some effort to cleanly use groovy objects from java.
All in all i would like to see a clean separation of the visual
definition and actual behaviour that should be in code anyway.
One nice idea I saw from the .NET guys is the concept of a visual state
manager.
http://timheuer.com/blog/archive/2008/06/04/silverlight-introduces-visual-state-manager-vsm.aspx
I think I like the idea. Coding state changes and their dependencies is
sometimes not trivial and mostly always hard to understand when you look
at the code only. So the idea of having
visual declarative elements (be it markup os dsl)
style information for the elements (oh no, not css)
different defined states of the declared elements
binding of elements to domain models
actual behaviour (aka the controller)
as separate concepts has some appeal to me.
If we could cleanly reference visual elements in a straightforward way
some things will get easier (think you declared a button in the visual
layer, how is it referenced in the controller?) a typical mess we have
today is when it comes to ui test automation. Look at the SWTBot
approach, coding names for the elements to make them testable. Thats
2008, I guess (sorry for beeing sarcastic, I have hard times with my UI
tests)
I think we still have lots of room for improvement. I'm just trying to
get some pieces together. I would be glad if you let me know what you
think.
Regards
Thomas