Saturday, June 16, 2007

More on 4GLs in UI Design

[Ayende]
The classic issue that we faced with 4GL is that they are really good for what they are supposed to do, and really bad for general purpose one. I with you on extensible frameworks, certainly, but I think that this is not an applicable method to develop most applications. Unless you build to extend, there is a high cost of it.

What if it just becomes HOW you build applications? Extension is not the only (or even the best) motive.

For example, using an Inversion of Control container like Castle Windsor is great if you want to build an extensible application because you can easily wire in new components and all of the dependency injection is taken care of for you. However it also solves a lot of problems in closed applications. In fact, I imagine it is most often used in the latter context.

I believe most applications waste a lot of time reimplementing common UI concerns and design patterns that have already been addressed by others. This happens because UI implementors are working with Forms and Controls and plain old controller classes all of the time. The higher level patterns don't emerge unless a significant investment in infrastructure occurs. Once you have the right infrastructure it imposes no additional burden. You have simply learned how to work differently.

I contend that you work better and you produce a higher quality product.

For example: How many times do we need to keep hacking together global undo/redo support, menu managers, background job managers, heterogeneous views, and progress monitors? It's ludicrously wasteful.

No comments: