Type faces: An idea to bridge typed and type-less worlds
Nowadays "type" is an important programming language construct. A type gives a certain authenticity and a certain gurantee and a certain solidity to the programming practice, not to mention the metadata aspects of it while using IDEs. By the same token it binds you to that contract and could prove to be inflexible at times. In the web world things are fluid: hashtables, dictionaries, xml, hierarchical data sets, relational databases. All of these structures seem to be horizontal and non-specific in nature. In this web log I want to think aloud to see if an idea that I call "type faces" will serve some needs.
Type faces briefly introduced
Let me start out with a specific need that got me started in this direction. When a web page is submitted you get a hashtable of values on the server side. The server side will process them using key names to retrieve the values. It is not that much of stretch to realize that one can use reflection to load up an object with these values and the server side programmer can work with the object instead.
What I haven't told you is that the incoming hashtable has enough fields for two objects and not one. Say invoice and employee. Now from the same hashtable you need to convert two objects as opposed to one. I call this model the push model where you are pre-specifying the objects. On the otherhand if you use a pull model where the objects "invoice" and "employee" are non-commital and they will pull their information from any data source including a dictionary. This is the essential idea of a "type face" where the "hashtable" object has been looked upon using a "type face" mirror so that it looks like an "employee" when looked through an "employee" typeface and looks like an invoce when looked through an "invoice" typeface. By separating the types from their concrete implementations, you can reuse these types on top of horizontal interfaces.
Typefaces applied for database output
Say, in the same application you are painting a grid. So you go to the server side and retrieved a row. Now this row based on the query may carry more than one object in one row. For instance it may have again an 'invoice' and an 'employee'. Using typefaces databases queries can be allowed to be efficient while the middle tier can look up on these rows via typefaces.
Typefaces applied to server side html controls
In asp.net for instance when the control is transferred to the server side your server side logic will access user controls as if they are objects. But largely these objects are horizontal. For instance for a grid control you will be using a DataRow. But a DataRow does not represent an "invoice" or an "employee" but a "DataRow" although the content of that DataRow is a composite of "employee" and "invoice". Typefaces can be used in this case aswell. This pattern should allow us to work on the middle tier using purely objects a typed world, while leaving the boundaries to the typeless world of SQL and Web.
Extending typefaces to XML and Hierarchical data sets
The full power of typefaces can be employed when the data actually has abstract interface of an object. What is this abstract interface of an object? XML, InfoSet or HierarchicalDataset. Essentially they are all the same but in different formats (May be with a couple of implementation differences). So when a complex type face is tagged on to one of these hierarchical data base, you can process the XML using an object paradigm to and fro from a middle tier.
This is just an idea that has been floating around in my mind for sometime. I haven't implemented it. I am also not sure if there are similar approaches taken in other places. The idea has parallels to data binding but carries the data binding to a more formal ground.
I am also not sure if the word "type face" is used in this context before. I suspect the "facade" pattern has some commonalities as well.
My other ramblings