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

["Boris Bokowski" <Boris_Bokowski@xxxxxxxxxx>]

We had a good discussion on the topic of using modeling for UIs at the 
Eclipse Summit Europe 08. What I took away from that discussion is that 
there are three areas where modeling makes sense:

1. At the widget level, where you would have a 1:1 mapping between the 
widgets and objects in your model. XSWT and XWT are in this space, as is 
Olivier's wazaabi 2. What I find important is that at runtime, you don't end 
up with twice as many objects, so being able to directly create widgets from 
a persistent representation is important. At the same time, having EMF 
objects that are again 1:1 mapped to SWT widgets is interesting for tooling 
purposes, so maybe what we should do is have a persistent format for SWT 
widgets, which can also be read in to create EMF objects if you are in 
"design mode".

2. At the application level, where you don't model the innards of your UI 
components (views, editors, ...) but you model how those components are 
glued together. An example of this is Application.ecore/Workbench.ecore in 
e4 (see org.eclipse.e4.model.workbench).

3. At an abstraction level higher than (1), but still concerned about 
"inner" UIs, are things like the proposed PMF project 
(http://www.eclipse.org/proposals/PMF). The idea here is that if you have a 
form-based UI, and need to create many forms, it is worth creating an 
abstraction that talks about the pieces making up that form-based UI in 
terms of semantics, not actual widgets. Models at this level would consist 
of information like "put a bunch of text fields with associated labels here, 
followed by a table with these columns and the standard Add/Remove buttons, 
followed by a Combo, etc."

Boris

"Thomas" <thomas.kratz@xxxxxxxxxx> wrote in message 
news:ghr7sk$ftg$1@xxxxxxxxxxxxxxxxxxxx
> HI Tom,
>
> I had a look at what you're doing With UFaceKit quite a while ago.Don't 
> get me wrong  I think currently we are confronted with what I would call 
> divergent evolution. There are many approaches out there (and no I won't 
> start my own toolkit). I think my dive into Riena was not deep enough. But 
> if you compare it to something like "if you want JSF, you should have a 
> look at Facelets and Seam" then what we have in client wonderland is a 
> little distracting.
>
> I took some first looks at the e4 demo when I read (I think it was Boris) 
> something about the  workbench model approach. Modeling the ui is
> surely promising.
>
> I signed up for the e4 mailing list so at least I can follow, and if I 
> think I can throw something in I surely will. But I don't see from the 
> wiki how far your brainstorming on declarative ui has led to a satisfying 
> result.
>
> I would love to get involved in your discussion!
>
> Thomas
>
> Tom Schindl schrieb:
>> 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
>>>
>>>
>>>
>>>
>>>
>>>
>>