Re: [e4-dev] Declarative UI

[Hallvard Trætteberg <hal@xxxxxxxxxxx>]

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