- 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.
