[news.eclipse.platform] Re: [Databinding, General UI] UI brainstorming,

[Tom Schindl <tom.schindl@xxxxxxxxxxxxxxx>]

Hi,

I think many of us are currently think about the same things how can we
succeed in writing as few lines of code as possible without loosing the
power we have nowadays.

There are multiple different Eclipse-Projects working on tasks you
mention in your post:

- e4-modeling the workbench: works on a consitent application model no
  matter which Widget-Toolkit-Implementation you use

- e4-declarative-ui: works on a declarative syntax to describe your ui

- e4-styling: works on styling currently CSS but if you want something
  different this is open to you

- riena: works on a high-level databinding-widget concept they named
         ridegts and themable widgets

- UFaceKit[1]: my the project I work on provides high-level
  databinding concepts simply one layer above low-level widget toolkits
  and core-databinding. Like Olivier explained in his waazabi answer
  UFaceKit has a similar view onto events where in fact there are only 2
  widgets who can really trigger an execution or better said a command
  (Button, MenuItem) all other things are property changes.

  Because UFaceKit's UI elements are a higher level widgets they come
  with many advanced features like support for rights-management,
  built-in styling support, ... . There's much more on UFaceKit than
  this but this is not the right forum.

- I'm not 100% a friend of a DSL e.g. JavaFX IMHO makes the mistake that
  one can't really use this whole API in pure Java but they force me to
  use their DSL at the very moment we have a Ecore-Model defined for the
  UI we could easily create a DSL.

- When it comes to EL one of the UFaceKit-members is working on such a
thing but I'm not 100% now how to attack this problem though I know this
is going to be a need for UFaceKit

Tom

[1]http://www.eclipse.org/proposals/ufacekit/

Thomas schrieb:
> 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
> 
> 
> 
> 
> 
> 


-- 
B e s t S o l u t i o n . at
--------------------------------------------------------------------
Tom Schindl                                          JFace-Committer
--------------------------------------------------------------------