Back to my usual DSL twatter. I think the idea of a DSL for UI components is both good - and limiting. You run into limitations when you need properties that a given component doesn't support. Then you keep adding properties to your component until the API becomes unwieldy. So, a DSL for UI is OK for lots of problems, but there are real edge case issues that need to be addressed. Try using a flex style MXML API to generate your HTML data grids and see how far you can get before the designer cries "yes, but every third row should be purple and I want to right align this but not that and . . . and . . . and . . ."

As for the concrete syntax, XML is a convenient way to store the information, but yu should also support programmatic configuration and a GUI builder (a la flex builder, the old Visual Basic toolkit, etc.). That way users can choose the combination of concrete syntaxes they want to use for different tasks, knowing they are all implemented through a combination of XML and programmatic changes to the tree.

Remember that even in Flex, it wouldn't be good for much if you didn't have the ability to programmatically set properties of components at runtime, so the real answer isn't GUI builder, XML or programatic API - its all three.

Posted by Peter Bell on Apr 10, 2007 at 04:19 PM UTC - 6 hrs

At Himalia, we are going the DSL approach.

While we think that abstraction is the key to make the productivity jump, it is also true, that sometimes you shouldn't get into so much detail.

With that in mind, we are supporting third party controls as first class citizens. You can also add your own controls in the language and start working with them.

The key is, the DSL stops at a certain detail level, and then, you should continue with UI control.

Posted by Leonardo Vernazza on Dec 04, 2007 at 10:11 AM UTC - 6 hrs