Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipse-incubator-e4-dev] Fw: Declarative UI roundup?


Comments below:

I find this theoretically cool but with my practical hat on I'm trying to understand the benefit this added abstraction buys us in Eclipse. My original thinking was that the declarative language should map 1:1 to SWT, because its SWT that actually does, well, the useful stuff.

I gave some background to explain where I'm coming from and what my experience is. Think of my model as a graphical model of how widgets are connected using databinding. I use XSWT for the widgets themselves, which as David says, is as close as you can come to SWT using XML.

I didn't mean to suggest using the abstract model in Eclipse, at least not in the platform! But based on my experience with XSWT, I have opinions about requirements for an XML-based representation of SWT.

Thus my thinking was perhaps along the lines Tom outlined: a declarative model written against SWT, exposing accurately the capabilities of SWT but in a serializeable format instead of Java code, providing a model which facilitates mapping to other declarative models.

As David wrote, this is XSWT: It uses reflection to be as close to SWT as possible, it is compact, it supports styles and scripting, it is easy to extend, we have plugins for rendering XSWT in a view, we have extended WTP's XML editor to make it more useful for editing XSWT.

However, XSWT's advantage is also its disadvantage: Since it uses reflection to be as close to SWT as possible, it does not have an explicit model/schema besides SWT's API. E.g. this makes it difficult to make the DOM "live" in the sense that updating it also updates the UI. I believe this specific problem can be fixed, but I would rather use EMF than XML.

> The main problem with going through XML and a renderer, > is that it only handles the creation process. I still need
>  > (in my case) SWT-specific code for attaching
>  > listeners and activating/deactivating widgets.

<naiveQuestion>Isn't this solved to a great degree through the use of databinding?</naiveQuestion>

To some extent, yes, but it only handles data, not activation/deactivation of widgets, moving them around etc. The workbench model that people are working on, based on Tom's initial experiment, shows the power of using EMF for describing the structure and keeping the concrete UI up-to-date.

Model: What I want is a declarative representation of the UI, based on an Ecore model that is a slight abstraction of the current toolkit (SWT), but close enough to be easily supported/implemented by it. (Perhaps UFaceKit is this slight abstraction?). The model should focus on the standard structure of all toolkits, particularly the parts you would like to manipulate to change the UI at runtime:
- widget hierarchy
- visibility and enablement of widgets
- value attributes of widgets, like label, text, selection
- standard visual attributes like color, icons, and styles containing such

If we pay attention to details, particularly naming, the mapping to SWT shouldn't be difficult or costly. I think XSWT's heuristics will be useful, and EMF annotations can be used to avoid guessing.

Extensibility: The model should in some way support adding toolkit-specific vocabulary, so we can use toolkit-specific data and constants when we need to, to avoid losing fidelity. E.g. although most toolkits support attaching layout to containers and layout data to each widget, the specific objects are fairly toolkit-dependent and we would like to be able to use those. Ideas: - support this as part of a styling mechanism, i.e. use styling as hints to the toolkit-specific mapping. - use EMF's support for XML anytype and wildcards at strategic places to add toolkit-specific data
- use reflection to generate part of the model

Databinding: I think such a model could support support databinding, including binding to Ecore data structures. It would be nice to support binding across plugin boundaries, e.g. binding the selection of an editor to the data shown in a related view. This may require exposing databinding attach points (IObservables), as a generalisation of techniques based on IAdaptable and ISelectionProvider.

Scripting: If Ecore is scriptable, the UI will be, too. I have already implemented good support for Ecore for Mozilla's Javascript.


Back to the top