[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Newsgroup Home]
[news.eclipse.platform] Re: [Databinding, General UI] UI brainstorming, (nearly) all stolen ideas
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