My Secret Life as a Spaghetti Coder
home | about | contact | privacy statement
Something of interest to developers who use Adobe offerings, InfoQ asked a few days ago, "Is XML the Future of UI Development?"

I remember thinking quite some time it would be cool if someone made it possible to develop desktop UIs with HTML - how much easier development would be. I'm still teetering on that though, because there are quite a few benefits to programmatically developing a user interface. That's where we get the crossroads that CF and MXML and others like them provide, which seem to embed so well when you are used to programming in tags.

I'm not so much a fan of the excess clutter, but it does have some appeal to me. What do you think?

Hey! Why don't you make your life easier and subscribe to the full post or short blurb RSS feed? I'm so confident you'll love my smelly pasta plate wisdom that I'm offering a no-strings-attached, lifetime money back guarantee!

Leave a comment

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 - 5 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 - 5 hrs

Leave a comment

Leave this field empty
Your Name
Email (not displayed, more info?)


Subcribe to this comment thread
Remember my details

Picture of me

.NET (19)
AI/Machine Learning (14)
Answers To 100 Interview Questions (10)
Bioinformatics (2)
Business (1)
C and Cplusplus (6)
cfrails (22)
ColdFusion (78)
Customer Relations (15)
Databases (3)
DRY (18)
DSLs (11)
Future Tech (5)
Games (5)
Groovy/Grails (8)
Hardware (1)
IDEs (9)
Java (38)
JavaScript (4)
Linux (2)
Lisp (1)
Mac OS (4)
Management (15)
MediaServerX (1)
Miscellany (76)
OOAD (37)
Productivity (11)
Programming (168)
Programming Quotables (9)
Rails (31)
Ruby (67)
Save Your Job (58)
scriptaGulous (4)
Software Development Process (23)
TDD (41)
TDDing xorblog (6)
Tools (5)
Web Development (8)
Windows (1)
With (1)
YAGNI (10)

Agile Manifesto & Principles
Principles Of OOD
Ruby on Rails

RSS 2.0: Full Post | Short Blurb
Subscribe by email:

Delivered by FeedBurner