Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [e4-dev] Declarative UI


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.


Back to the top