Home » Eclipse Projects » Eclipse Platform » [Databinding, General UI] UI brainstorming, (nearly) all stolen ideas
| [Databinding, General UI] UI brainstorming, (nearly) all stolen ideas [message #333420] |
Wed, 10 December 2008 15:08  |
 Thomas Kratz
Messages: 165
Registered: July 2009 |
Senior Member |
|
|
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-intr oduces-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
|
|
|
| Re: [Databinding, General UI] UI brainstorming, (nearly) all stolen ideas [message #333427 is a reply to message #333420] |
Wed, 10 December 2008 18:59  |
Eclipse User |
|
|
|
Originally posted by: omoises-nospam.nordnet.fr
Hi Thomas,
I am working on a open source (EPL) project allowing the developer to
design its UI using declarative EMF models.
Models are live models (when the user changes the view, changes are
reflected in the model, and vice versa..)
The benefit of a such approach is that almost everything is a structural
feature (in EMF, structural feature means reference or attribute).
For instance, focus is an boolean attribute, then when a widget gains
the focus, the value is set from false to true ...
For a small subset of cases, we need action trigers (especially for push
button or menu selection, because it requires two state changes).
Regarding the databinding, I am currently working on it. My wish is to
provide a declarative mechanism based on workflow/dataflow concepts.
The databinding engine is still in progress and is not yet released.
If you want to test the existing work, you could have a look at
http://wiki2.wazaabi.org/index.php?title=InstallationANDTest
There is only few widget, I force myself to have a first binding engine
before to add other widgets.
I will be happy to receive any hints/critisicm about this work.
Olivier
Thomas a écrit :
> 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-intr oduces-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
>
>
>
>
>
>
|
|
|
| Re: [Databinding, General UI] UI brainstorming, (nearly) all stolen ideas [message #333428 is a reply to message #333420] |
Wed, 10 December 2008 20:23 |
Thomas Schindl
Messages: 6651
Registered: July 2009 |
Senior Member |
|
|
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-intr oduces-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
------------------------------------------------------------ --------
|
|
|
| Re: [Databinding, General UI] UI brainstorming, (nearly) all stolen ideas [message #333439 is a reply to message #333427] |
Thu, 11 December 2008 14:04 |
Thomas Kratz
Messages: 165
Registered: July 2009 |
Senior Member |
|
|
HI Olivier,
I had a look at what you are doing. What I didn't get in the short time
is how you do the bindings ?
Can you give me a pointer where to look at ?
Regards Thomas
Olivier Moïses schrieb:
> Hi Thomas,
>
> I am working on a open source (EPL) project allowing the developer to
> design its UI using declarative EMF models.
> Models are live models (when the user changes the view, changes are
> reflected in the model, and vice versa..)
>
> The benefit of a such approach is that almost everything is a structural
> feature (in EMF, structural feature means reference or attribute).
> For instance, focus is an boolean attribute, then when a widget gains
> the focus, the value is set from false to true ...
>
> For a small subset of cases, we need action trigers (especially for push
> button or menu selection, because it requires two state changes).
> Regarding the databinding, I am currently working on it. My wish is to
> provide a declarative mechanism based on workflow/dataflow concepts.
>
> The databinding engine is still in progress and is not yet released.
> If you want to test the existing work, you could have a look at
> http://wiki2.wazaabi.org/index.php?title=InstallationANDTest
>
> There is only few widget, I force myself to have a first binding engine
> before to add other widgets.
>
> I will be happy to receive any hints/critisicm about this work.
>
> Olivier
>
>
> Thomas a écrit :
>> 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-intr oduces-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
>>
>>
>>
>>
>>
>>
|
|
|
| Re: [Databinding, General UI] UI brainstorming, (nearly) all stolen ideas [message #333441 is a reply to message #333428] |
Thu, 11 December 2008 14:25 |
Thomas Kratz
Messages: 165
Registered: July 2009 |
Senior Member |
|
|
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-intr oduces-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
>>
>>
>>
>>
>>
>>
>
>
|
|
|
| Re: [Databinding, General UI] UI brainstorming, (nearly) all stolen ideas [message #333444 is a reply to message #333441] |
Thu, 11 December 2008 15:21 |
Boris Bokowski
Messages: 272
Registered: July 2009 |
Senior Member |
|
|
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@eiswind.de> wrote in message
news:ghr7sk$ftg$1@build.eclipse.org...
> 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-intr oduces-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
>>>
>>>
>>>
>>>
>>>
>>>
>>
|
|
|
| Re: [Databinding, General UI] UI brainstorming, (nearly) all stolen ideas [message #333446 is a reply to message #333444] |
Thu, 11 December 2008 15:31 |
Thomas Schindl
Messages: 6651
Registered: July 2009 |
Senior Member |
|
|
Boris Bokowski schrieb:
> 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
http://www.eclipse.org/proposals/pmf/
Tom
--
B e s t S o l u t i o n . at
------------------------------------------------------------ --------
Tom Schindl JFace-Committer
------------------------------------------------------------ --------
|
|
|
| Re: [Databinding, General UI] UI brainstorming, (nearly) all stolen ideas [message #333447 is a reply to message #333444] |
Thu, 11 December 2008 15:56 |
Thomas Schindl
Messages: 6651
Registered: July 2009 |
Senior Member |
|
|
Boris Bokowski schrieb:
> 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".
Well this is where we both disagree. I take the point that it doesn't
really matter if those objects stay in memory. On the other hand say if
an Ecore-Model backing up the UI stays in memory you could generate some
benefits like you'd have to code your own:
- XPath like querying out of box to find Widgets
(UFaceKit by the way provides such a feature this we are going to use
this for our binding story)
I think here along the following lines (I just made up this syntax so
please don't blame me):
ui.xml:
-------
<window>
<label text="City" />
<text />
</window>
bind.xml
--------
<bindings>
<bind-value
widget="/window/text[0]/@text"
value="/city/@name" />
</bindings>
- Easy-Client-Server split
Server-Model <=> Client-Model <=> Widget-Toolkit
Network JVM
- ...
This allows to optimize the client-server traffic without the need to
hand-craft a protocol.
I still believe that a medium sized RCP-Application is not built of so
many widgets that you'll notice it. If you think about CDO which has
quite smart logic to wipe unreferenced model-objects this gets an even
smaller problem. Where I agree with you is that this should be an opt-in
model so I should be able to decide myself whether I want a Live-Model
or not but I would not limit it on design mode.
Tom
--
B e s t S o l u t i o n . at
------------------------------------------------------------ --------
Tom Schindl JFace-Committer
------------------------------------------------------------ --------
|
|
|
| Re: [Databinding, General UI] UI brainstorming, (nearly) all stolen ideas [message #333448 is a reply to message #333439] |
Thu, 11 December 2008 16:10 |
| Eclipse User |
|
|
|
Originally posted by: omoises-no-spam.no-spam-nordnet.fr
Hi Thomas,
My work on the databinding is actually in progress.
Nothing has been published yet and I need few days before to release any
new part of my work.
The main concepts of the databinding are :
1°) models are declaratively bounds (EMF<->EMF or EMF<->POJO/beans)
2°) sources and targets (needed by the binding processes are mainly set
at runtime)
3°) databinding is a specific case of a workflow (usually a chain of
primitive tasks like copy, transformation ...
4°) binding operations are oriented (UI->domain is not the same as
domain->UI)
Let's focus on a very simple example :
*given a class Person with 2 String properties (firstName, lastName)
*given a form (container) containing 2 text fields
UI->domain means:
when the focus of a text fields is lost, copy the value into the
appropriate property.
We need two times the same tasks and events : copy (task) and
focusChanged (event).
We could model this like (for the first field and property, the second
is the same):
property changed event : path="children[@id='firstName']/@focus",
value="false"
copy task : sourcePath="children[@id='firstName']/@text",
targetPath="firstName"
Of course, since we provide pathes, we need, before to run the binding
process, set the source and target contextes. Contextes are runtime
instances. In our case, the 'form' instance (EObject) as source and the
Person instance (EObject) as target.
More complex bindings could act as dataflows, chaining primitive tasks
which transform a given dataobject (as source) into another one (target).
The model support also conditional branches (validations, errors, ...)
At the end, since every UI part is a model, we could use the same
mechanism for UI to UI binding (for instance, a checkbox makes visible a
part of a form),
It will also be possible to change layout constraints when a given event
is triggered (for this last exmaple, I am not sure it could be usefull ;-) )
Regards,
Olivier
Thomas a écrit :
> HI Olivier,
>
> I had a look at what you are doing. What I didn't get in the short time
> is how you do the bindings ?
>
> Can you give me a pointer where to look at ?
>
> Regards Thomas
> Olivier Moïses schrieb:
>> Hi Thomas,
>>
>> I am working on a open source (EPL) project allowing the developer to
>> design its UI using declarative EMF models.
>> Models are live models (when the user changes the view, changes are
>> reflected in the model, and vice versa..)
>>
>> The benefit of a such approach is that almost everything is a
>> structural feature (in EMF, structural feature means reference or
>> attribute).
>> For instance, focus is an boolean attribute, then when a widget gains
>> the focus, the value is set from false to true ...
>>
>> For a small subset of cases, we need action trigers (especially for
>> push button or menu selection, because it requires two state changes).
>> Regarding the databinding, I am currently working on it. My wish is to
>> provide a declarative mechanism based on workflow/dataflow concepts.
>>
>> The databinding engine is still in progress and is not yet released.
>> If you want to test the existing work, you could have a look at
>> http://wiki2.wazaabi.org/index.php?title=InstallationANDTest
>>
>> There is only few widget, I force myself to have a first binding
>> engine before to add other widgets.
>>
>> I will be happy to receive any hints/critisicm about this work.
>>
>> Olivier
>>
>>
>> Thomas a écrit :
>>> 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-intr oduces-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
>>>
>>>
>>>
>>>
>>>
>>>
|
|
|
| Re: [Databinding, General UI] UI brainstorming, (nearly) all stolen ideas [message #333460 is a reply to message #333447] |
Fri, 12 December 2008 08:32 |
Thomas Kratz
Messages: 165
Registered: July 2009 |
Senior Member |
|
|
Modeling UIs is as i found out a topic thats not really new. I have my
concerns whenever people try to overabstract ui's in terms of (Form a
and form b are all the same) so I think the modeling widgets approach is
the way to go. I haven't thought this really through, but what I had in
mid tonight was another thought of abstraction. I think that we have
different aspects in of widgets, they have a semantic, the have state,
the have appearance (which may depend on state). I think we need some
kind of expressions in the model (correct me if not) be it xpath or el
or any kind of scripting. for the binding approach i like the idea of
convention over configuration. for eg. i currently prototype a fully
editable table abstraction that binds to my model and knows mostly
everything about how to edit properties.
what distracts me overall is that we have so many ui frameworks out
there that somehow all do the same. do you believe that I'm too far from
reality when I insist that a breakthrough would be if we had an
abstraction layer that describes ui on a semantic level in a common way ?
Tom Schindl schrieb:
> Boris Bokowski schrieb:
>> 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".
>
> Well this is where we both disagree. I take the point that it doesn't
> really matter if those objects stay in memory. On the other hand say if
> an Ecore-Model backing up the UI stays in memory you could generate some
> benefits like you'd have to code your own:
>
> - XPath like querying out of box to find Widgets
> (UFaceKit by the way provides such a feature this we are going to use
> this for our binding story)
>
> I think here along the following lines (I just made up this syntax so
> please don't blame me):
>
> ui.xml:
> -------
> <window>
> <label text="City" />
> <text />
> </window>
>
> bind.xml
> --------
> <bindings>
> <bind-value
> widget="/window/text[0]/@text"
> value="/city/@name" />
> </bindings>
>
>
> - Easy-Client-Server split
>
> Server-Model <=> Client-Model <=> Widget-Toolkit
> Network JVM
> - ...
>
> This allows to optimize the client-server traffic without the need to
> hand-craft a protocol.
>
> I still believe that a medium sized RCP-Application is not built of so
> many widgets that you'll notice it. If you think about CDO which has
> quite smart logic to wipe unreferenced model-objects this gets an even
> smaller problem. Where I agree with you is that this should be an opt-in
> model so I should be able to decide myself whether I want a Live-Model
> or not but I would not limit it on design mode.
>
> Tom
>
|
|
|
| Re: [Databinding, General UI] UI brainstorming, (nearly) all stolen ideas [message #333462 is a reply to message #333460] |
Fri, 12 December 2008 08:42 |
Thomas Kratz
Messages: 165
Registered: July 2009 |
Senior Member |
|
|
I see thats what PMF seems to be all about :) Should have read this ..
I guess I have to dive into that.
Thomas schrieb:
> Modeling UIs is as i found out a topic thats not really new. I have my
> concerns whenever people try to overabstract ui's in terms of (Form a
> and form b are all the same) so I think the modeling widgets approach is
> the way to go. I haven't thought this really through, but what I had in
> mid tonight was another thought of abstraction. I think that we have
> different aspects in of widgets, they have a semantic, the have state,
> the have appearance (which may depend on state). I think we need some
> kind of expressions in the model (correct me if not) be it xpath or el
> or any kind of scripting. for the binding approach i like the idea of
> convention over configuration. for eg. i currently prototype a fully
> editable table abstraction that binds to my model and knows mostly
> everything about how to edit properties.
>
> what distracts me overall is that we have so many ui frameworks out
> there that somehow all do the same. do you believe that I'm too far from
> reality when I insist that a breakthrough would be if we had an
> abstraction layer that describes ui on a semantic level in a common way ?
>
>
>
> Tom Schindl schrieb:
>> Boris Bokowski schrieb:
>>> 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".
>>
>> Well this is where we both disagree. I take the point that it doesn't
>> really matter if those objects stay in memory. On the other hand say if
>> an Ecore-Model backing up the UI stays in memory you could generate some
>> benefits like you'd have to code your own:
>>
>> - XPath like querying out of box to find Widgets
>> (UFaceKit by the way provides such a feature this we are going to use
>> this for our binding story)
>>
>> I think here along the following lines (I just made up this syntax so
>> please don't blame me):
>>
>> ui.xml:
>> -------
>> <window>
>> <label text="City" />
>> <text />
>> </window>
>>
>> bind.xml
>> --------
>> <bindings>
>> <bind-value
>> widget="/window/text[0]/@text"
>> value="/city/@name" />
>> </bindings>
>>
>>
>> - Easy-Client-Server split
>>
>> Server-Model <=> Client-Model <=> Widget-Toolkit
>> Network JVM
>> - ...
>>
>> This allows to optimize the client-server traffic without the need to
>> hand-craft a protocol.
>>
>> I still believe that a medium sized RCP-Application is not built of so
>> many widgets that you'll notice it. If you think about CDO which has
>> quite smart logic to wipe unreferenced model-objects this gets an even
>> smaller problem. Where I agree with you is that this should be an opt-in
>> model so I should be able to decide myself whether I want a Live-Model
>> or not but I would not limit it on design mode.
>>
>> Tom
>>
|
|
|
| Re: [Databinding, General UI] UI brainstorming, (nearly) all stolen ideas [message #333464 is a reply to message #333460] |
Fri, 12 December 2008 08:52 |
Thomas Schindl
Messages: 6651
Registered: July 2009 |
Senior Member |
|
|
Thomas schrieb:
> Modeling UIs is as i found out a topic thats not really new. I have my
> concerns whenever people try to overabstract ui's in terms of (Form a
> and form b are all the same) so I think the modeling widgets approach is
> the way to go. I haven't thought this really through, but what I had in
> mid tonight was another thought of abstraction. I think that we have
Yes I agree here with you. Though I still believe we should not
model/describe the direct implementation (SWT, ...) 1:1 which XSWT, XWT
do but stay at a level similar to what JFace is nowadays in Eclipse land
and one can easily transform JFace ideas like viewers, actions, ... .
Whether some is afterwards adding one more layer of abstraction above it
and do an m2m-transformation is some thing people can do afterwards.
An example might make this clear. I don't want to model a MenuItem but
the higherlevel of an Action which widget is used to represent this
action in the UI can be an MenuItem, RibonItem, ToolBarItem, ... .
Porting JFace concepts to other technologies is easily possible at
Nebula we have Viewers for Grid and Gallery or for example in UFaceKit
we did this with JFace-Viewers where we ported the concept to Swing and QT.
> different aspects in of widgets, they have a semantic, the have state,
> the have appearance (which may depend on state). I think we need some
> kind of expressions in the model (correct me if not) be it xpath or el
> or any kind of scripting. for the binding approach i like the idea of
Not sure what you mean with expressions in model?
> convention over configuration. for eg. i currently prototype a fully
> editable table abstraction that binds to my model and knows mostly
> everything about how to edit properties.
Yes I also did this for a customer (setting up a table with editing,
sorting, auto-filtering is done in 10 lines of code) but I'm not sure
this is a good idea for a framework. Whenever a framework forces people
into some programming style they get scared and don't use it and beside
this it may no allow me to fully exploit the possibilities of the
technologies.
>
> what distracts me overall is that we have so many ui frameworks out
> there that somehow all do the same. do you believe that I'm too far from
> reality when I insist that a breakthrough would be if we had an
> abstraction layer that describes ui on a semantic level in a common way ?
>
Sure but before we can do that we need to define what the UI is we want
to describe. Is it a SWT, JFace, ... what do we describe. Maybe a
mock-up example can clarify what you think about.
Tom
--
B e s t S o l u t i o n . at
------------------------------------------------------------ --------
Tom Schindl JFace-Committer
------------------------------------------------------------ --------
|
|
|
Goto Forum:
Current Time: Fri Sep 20 14:29:23 GMT 2024
Powered by FUDForum. Page generated in 0.05753 seconds |
] 
Search
Help
Register
Login
Home
