User Interface Implementation Concerns (and 4GLs)

Ayende and I are having an interesting little discussion about various User Interface implementation concerns. I figured it would be good to copy it over here for further discussion. (I need to start using blog trackbacks instead of always replying directly in comments.)

In response to my Information in Software post, he says:

[Ayende]
It is worth point out that most organization can't agree on what something as fundamental as the Customer within the organization. This is because different parts of the organization are responsible for different aspects of the customer, and they have radically different needs.

As Jeff points out, software that is open & extensible usually carry a price tag of six figures as well as a hefty customization fee. That is just the nature of the beast, because being a generalist costs, because the business doesn't care if you you can handle fifty different ideas of customers, they want your to fit their idea of customer, do it well, and fit with the different view of a customer within the organization. That doesn't come easily.

We certainly agree on this point. I don't expect common base-line models to appear. However, in applications like Eclipse, I have seen how having a common meta-model and a model-based application framework works wonders. In Eclipse, the underlying model is usually adapted to a common meta-model that is then used for presentation. Likewise, the model objects themselves are adapted in various ways to make them usable in different contexts. So I gave this example.

[Jeff]
You'll see UI frameworks where this has been done. JFace, used by Eclipse, defines IContentProvider interfaces to adapt models of various kinds for presentation purposes. So there are IListContentProviders and ITreeContentProviders.

Likewise, the model objects themselves are often adaptable to other formats via interfaces like IAdaptable. Thus a Java Package object can be adapted to a Directory Resource and manipulated in any of the ways a directory might be manipulated. Adapters are often contributed by external plugins to add new interpretations to existing objects so that they can be used in a variety of different contexts.
These are very powerful approaches indeed! Imagine what would happen if all applications were built like this?

Ayende then points out the limitations of this approach and is concerned about the ultimate cost.

[Ayende]
In the UI, it is possible to do so because you have a limited set of things that you can display, lists and tree and objects are just about it. Likewise for things that _can_ be adapted. Hierarchy to directory is very natural thing, but it can't work for a graph, for instance.

> Imagine what would happen if all applications were built like this?

I do, imagine the cost for this. That is the problem.

But I'm not so sure. I've seen it work well before... At least when you can get everyone to play by the same rules.

[Jeff]
It's been my experience writing plugins for Eclipse that with a well-designed core set of abstractions the costs are much diminished. In fact, the cost of integrating a few extra actions and views into a platform like Eclipse appears to be much less than it would be to build all of the action and view management code you would need on your own.

Witness the difficulty of building an add-in for Visual Studio versus Eclipse. Visual Studio is much more difficult to extend because it provides comparatively primitive services. Extending views with new actions requires individually hooking into the menus and toolbars for those views. There's no way to simply contribute an action on the basis of the underlying model object that is being presented and selected by the user.

At the risk of suggesting we all go framework-happy, I am curious as to whether the overall quality of software applications would improve if they were built atop a better platform rather than all pretty much working from the ground up.

For example, what would be the benefits of using common abstractions and DSLs to specify and implement common participants in a UI such as the models, views, actions, undo/redo mementos, background jobs, etc...
In other words, should we be writing applications using a 4GL?

Does this make sense?

Edit: The Blogger Preview window sucks. It displays extra line breaks where there are none even though I disabled automatic insertion of <br/> tags. I can't trust it.