[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [e4-dev] Declarative UI
|
Tom,
If I understand you correctly, you argue that we must ensure that the programmer
formulates the CSS against the abstract widget model, instead of the concrete
SWT structure. If not, we get the problem you outline. The reason I didn't see
any problem, is that I thought this was agreed upon, and hence implicit in the
discussion.
In my view, CSS may be used in three ways:
- Purely abstract, by providing default values within the model (the model I
call the toolkit model or TM). E.g. you can express that an abstract text field
should red if it is invalid.
- Abstract to concrete, to give hints to the mapping process from TM to SWT (or
Swing). E.g. you can express that the abstract style INVALID should map to the
SWT.COLOR_RED, or even that a certain BORDER style should use a specific image
for the border (assuming an implementation using an intermediate Composite).
- Concrete, to give hints about purely toolkit specific details.
Now, there are two important issues:
1) How do you distinguish between the abstract and concrete hierarchy?
2) What limitations (pitfalls) are there when you refer to concrete elements,
that to some extent is implementation dependent?
I don't have any answers, but I can imaging using a naming scheme to
differentiate between concrete and abstract classes, e.g. "Text" is abstract and
"text" is concrete. However, I don't know CSS well enough to understand what's
possible.
Implementation-wise, I think it should be possible to annotate an SWT control
hierarchy (when it is created), using the data table, with enough information
about the abstract structure, to be able to navigate and skip
intermediate/artificial Controls.
Hallvard