[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[eclipse-incubator-e4-dev] CSS and declarative UI
|
Hi all,
I've just become member of this list, so let me first introduce myself before
making some comments to the "CSS and declarative UI round up" thread".
I'm a researcher working in the field of model-based user interface design. In
my thesis I developed a UI dialog modeling language called diamodl (see
http://www.idi.ntnu.no/~hal/research/diamodl/) and over the last years I've been
working on Eclipse-based tools for it, both editor (GMF) and runtime (EMF,
Databinding, XSWT/SWT and Javascript). Diamodl essentially models flow of data
in a data binding graph and activation of dialog elements based on a State
charts. Thus, the model can be thought of as glue between the application data
and the toolkit, i.e. an abstract/logical UI model as opposed to a model of the
actual widgets.
So, what is the relevance for e4? I see several:
- I've been committing code to XSWT the last years, to make it more usable for
my diamodl runtime, like XSWT stylesheets, javascript, more flexible XML.
(Unfortunately, there is no release with these features, but the code is in
CVS.). Based on this work, I have some thoughts about how it may be improved to
include other hierarchical and related data, like view structures and data
binding graphs.
- Scripting support has been mentioned as important for e4, and Rhino has been
integrated with both EMF and XSWT as part of my work.
- Since the diamodl runtime is based on so many relevant technologies, diamodl's
concepts (variables for data, computations for data transformations and
connections for data bindings) may also be relevant for a model-based e4.
Some more specific thoughts on the issues in this discussion:
Using EMF for modeling the GUI, what does that entail?
- One of the advantages of XSWT is that it does not rely on a closed model,
since it uses reflection for looking up classes, constructors, methods and
properties. If we go for an EMF model, we must make sure it is easy to extend it
at runtime, e.g. by loading an EMF fragment for a new widget or generating a
model fragment based on reflection (possibly pregenerated).
- It's not really clear what the role of EMF will be. One possibility is to use
it as the runtime representation of the UI, so that a serialization and
subsequent deserialization of it is enough to restore the relevant state. This
will require a model that includes more information than a model of the static
structure. E.g. things like activation state, selection etc must be included.
Ideally, this representation should be independent of the toolkit, so that the
same model instance may be used by SWT- and AJAX-based UIs. This also means that
there must be a mechanism for adapting the "logical" EMF model to a specific
toolkit. Perhaps this will be the role of XSWT/EXSWT, i.e. instead of mapping
directly from XML to GUI, (E)XSWT will map from (an) EMF (model) to GUI and keep
them synchronized.
- EMF annotations may play a role in supporting the mapping from EMF to widgets.
E.g. a Text EClass may model the SWT Text widget, and the logic for mapping
between them partly described by EMF annotations on the EClass, EOperations and
EAttributes.
- Databinding will then be EMF to EMF, rather than EMF to SWT, with XSWT
handling EMF to SWT.
- CSS could be used for deriving (defaulting) EMF values from other EMF values,
as well as supporting the EMF to SWT mapping encoded by XSWT.
- The model should include some notion of activation state, like (dis)attached,
(de)active, (in)visible etc. This is useful an several ways, e.g. for storing
the workbench state, building the actual GUI lazily (a problem with large XSWT
files) and for listening to (when an editor or view is activated).
Best regards,
Hallvard Trætteberg, Associate Professor at the Dept. of Computer and
Information Sciences, Norwegian Univ. of Science and Technology.
P.S. Tom: You say you're going to Norway for your vacation. Since I'm Norwegian,
please feel free to ask questions or even drop by!