- 1443 Declarative UI sucks? Create your own!
- 1480 Extensible EMF Switches
- 1483 Annoyed by all those similar looking interfaces: IMemento, IConfigurationElement, IPreferenceStore, IDialogSettings, ILaunchConfiguration...
- 1484 JFace/SWT Tables turned upside down
It seems that I am contradicting myself, because in 1443 I propose to create your own (copy) of a declarative UI and in 1483 I whine about all those similar looking interfaces. How does this go together?
Well, in the case of all the different property stores, they all do the same and having 10 different classes/interfaces is indeed annoying. On the other hand. I simply do not believe that there is "the" declarative UI that solves everybody's problems. Whenever you try to create the ultimate declarative UI you are doomed to fail because it is either simple but too restrictive or powerful but too complicated (I'd be very happy if someone could prove me wrong).
The idea of a domains specific language is to be Domain Specific! One could argue that UI is a domain and a (e.g. xml based) declarative UI is a domain specific language for creating UI. But, in reality UI is not UI. It's like creating a domain specific language for programming. You end up creating a Turing complete general purpose language. OTOH, if you want to create a domain specific language for form based UI on top of EMF you have a good chance it becomes a good abstractions. But do not expect this language to be used to create something like JDT or PDE.
I do not believe there is the ultimate declarative UI language. But I believe that saving properties is so universal (and simple) that one 'language' should be sufficient.
Hi Michael,
ReplyDeleteYou say you don't believe there is the ultimate declarative UI language.
Questions.
1) What UI languages have you seen that are declarative?
2) What properties of declarative UI languages do you think contribute most to reduction in lines of code?
3) What is the "essence" of UI description that cannot be regarded as boilerplate?
4) Have you ever come up with user stories and corresponding use cases/scenarios for generalizing your DSL into an all-encompassing one?
On 4), I would say you should refrain from saying an all-encompassing one is impossible, as you would need to have at least formally tried. Otherwise, you are sharing an anecdote, not scientific evidence.
Great questions!
ReplyDeleteMy opinion is not a formal or scientific statement. It is about practicability. I am sure it is possible to create an ultimate declarative UI that can handle all situations. But that would become hard to master (see my blog entry Why is RCP, EMF, p2, databinding... so hard to learn?), because it would have to be able to deal with all possible aspects of UI design.
I simply do not believe there is ONE simple easy to learn and easy to use declarative UI that can handle all aspects of UI design.
There might be extensible declarative UI where it is possible to create a small sub-language for a specific domain but then you'd have created a new DSL for your domain.
Examples: if you want to create an IDE (like eclipe JDT) you'd probably need a different set of UI abstractions than if you want to create a form based entry system for a insurance contracts. Or if you want to visualize the internals of an embedded system.
In all those cases the system has some data model (it might be POJO, EMF, a database or a whatever). The datamodel might be extensible and the UI should bind easyly to the model and the system might constrain what UI elements you are allowed to use.
The binding of the UI to the datamodel could be done with some abstraction but would be different for different data models.
Similarly, the model constraints and workflow might be quite different. E.g the validation and control flow for the insurance contracts might be quite different form the visualization of the internals of an embedded system.
The commonalities within such a system are often big enough to create abstractions to simplify the creation of the UI for that domain....
But John, maybe you know the ultimate declarative UI language. I'd love to be proven wrong!
Michael