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

[Thomas <thomas.kratz@xxxxxxxxxx>]

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