So, my idea was to follow the nice development models that often exist at a platform level in UI architecture and apply them to the view components of a design pattern - particularly with an focus on extensibility. But I needed some way for the framework to tell me style information about the data itself. And to present that information without using HTML. Because, as I mentioned earlier, there's a value in using alternative markup configurations for standard UI elements to improve usability or create interface features.
Which is a pretty interesting task: having to describe a table without using an actual <table> tag. It occurred to me that this is nearly a textbook definition of XML - a format to couple metadata to data.
So I decided it could work something like this:
<table>
<header>
<cell> ...
<row>
<cell> ...
Meaning: the table layout logic is, at a low level, distinct from the resultant markup. A distinction that could apply to various other common areas of web application interface data. For example:
<messages>
<message type="error">
...
<message type="status">
...
What's really nice about this approach is that it allows for extensibility as additional attributes can be entered by application-specific or downstream inheritors. For example, if a developer wanted to mark a row as a totals row, and change its look-and-feel downstream, she could add an attribute in a specific table service:
<table>
<header>
<cell sortable="true"> ...
<row>
<cell totals="true"> ...
This idea is pretty powerful. And, most importantly, it removes the dependency of higher-level technology in the lower UI framework layers. (What do the architect kids say? "Dependencies go down. Data goes up." or something...) The application UI layer could specify a generic XSL file to transform tables and module/page-specific tags could specify more specialized markup designs.
I'd be happy to see this kind of separation in UI frameworks because frameworks, by design, resist change. Which is part of what's great when using a platform - it's bedrock. But if dependencies build up around the philosophy which allows for markup at a component level, it's going to be difficult to make interface improvements at the application or module level. And I want to avoid what I've seen in the design cycles for so many web applications - which is to create a situation where a developer has to go back to a usability web designer and say, "I'm sorry. It's just not going to be possible to make that improvement. We didn't plan for that possibility."
But with co-operation and a change in how we approach how HTML is generated for large-scale web applications, we don't have to make that excuse.
So...my open letter to framework developers would open like this: Here's a powerful idea - why not create a space for interface improvements by separating layout logic from markup?
It would make usability bears like myself very, very happy.
~Love, Massless
P.S. Next, I can provide a few examples in Java of how I've implemented something like this and show the gains I'd achieved (as well as what was lost or could be improved).
P.P.S. Also, maybe I'm rash, but I no longer use the <a> tag within extensible UI architectures that I'm building once I realized its inherent evil.
huh? Crazy? Drunk?
Or... oh-!
....genius.... ?