I’m trying to figure out what objects look like.
I know what they do, I can describe them, and I know what properties and methods they have. Basically, all there is to know about them. But I realized that I have no idea what they look like.
After programming countless user interfaces, I realized that what I’m really doing *most of the time* is giving objects faces. I’m giving the user a way to see an object and interact with it, creating a bridge from the world of code to the world of human beings. But I don’t think this is the optimal way to do things. In an ideal world, I shouldn’t have to write code every time I want to include an object in a user interface.
It gets even worse in Web applications (all I’m really interested in), where the user interface is so disconnected from the back end that pretty much everything is usually hand-written. And even in cases where the user interface is partially generated from server objects like some OR/M tools do, the objects don’t actually exist on the client, it’s more like a shadow of the object. It bears no real relationship to the object itself and there’s no way to attach it to a different back end, like you would need to do if you wanted to use objects that lived in different locations on the Internet.
So I decided that the objects themselves should figure out what they look like, I’ll just give them places to live. I decided to call these object containers for lack of a better word.
In my code on the client, I’m using DIV’s for these containers. I really like this idea a lot because you could theoretically make anything an object container, including individual displays, different browsers, or even 3D objects. But I’m using HTML DIV’s for now.
Object containers exist on a Web page and are automatically "parsed" when the page is loaded. I can place three different object containers on the page, arrange them where I think the objects would look best, and when the page is loaded the containers will be automatically populated with their objects, which will then take care of displaying themselves.
Objects can do whatever they want inside of their containers and display themselves however they want to be displayed. That includes creating new containers and putting other objects inside of them, creating a kind of recursive autonomy. And the objects inside the containers also retain all of their normal properties and methods so you can still use them as objects as well.
The parsing routine that automatically runs when the page is loaded is responsible for getting the objects from the server and putting them in the containers where they live. I quickly figured out in order for the parser to figure out what is supposed to be in a container, the container needs to give the parser a few hints. To be exact, the container needs to tell the parser three important things:
- The address of the object
- How the object should be displayed
- The type of the object
The Address of the Object
The address of the object, in my scheme anyway, is a URI. I’ve written pretty extensively about object addressing using URI’s in the past, this is why. Once the parser has the object address, it has access to the object itself. One of the key advantages of a URI-based addressing scheme is that I can mix and match objects that live on completely different domains and servers on the same page.
How the Object Should be Displayed
One issue that came up was that I had to be able to use objects differently at different times. For example, sometimes I wanted a detailed view of an object, other times I wanted to edit it, and other times all I wanted was a simple text representation of it. After trying several different solutions, I figured out that what I really want are different views of the same object, just filters that change the way the object looks and acts.
As of right now I been able to determine just three different standard views that are always necessary (if you think I’m missing one please shout). They are:
- A one-line text view, which just renders a one-line text representation of the object for embedding in lists and text.
- A detail view, which shows the object’s detailed properties. For a blog post, for example, the detailed view would show a few important properties and the text of the post.
- And an edit view, which is similar to the detail view but renders the object properties as editable controls. This is similar to a standard dialog box.
What works really well about this is that the object properties, if they are references to other objects, can be rendered in their own containers inside of the views. In other words, if a BlogPost object on a page has an Author property which is a Person object, the BlogPost detail view can just create a container for the Author property and let the Author object render itself into its own container.
The Type of the Object
I found it necessary for programmatic reasons to know the type of the object in order for the parser to work. Nothing very special about this, I actually wish I could figure out a way to do without it. Maybe a Javascript guru could eliminate this step, but I couldn’t figure out a way around it.
So, what does an object look like?
The answer is: the object decides. I just give it a place to live and the parser goes out to the object itself on the server and asks for the two things: The HTML representation of the object and the object properties for use in Javascript. It tells the object which view it needs, and the object applies the corresponding XSLT template to its data, returning the resulting HTML for display in the container. That way the server can control the way the object looks and feels, and different servers can even provide their own, completely different visual interpretation of the same type of object. A link is also maintained between the container and the object itself so that the object can notify the container of changes and the container can notify the object of changes and switch between views.
So at a broad level I’m really more concerned about providing the frame for the picture of the object than the picture itself. In my test code I instantiate an object using this HTML code on a page:
<div id="MyFavoriteObject" title="jasonkolb.atmy.name/Person/MyDad" class="Object_Person_Detail" style="position: absolute; left: 10; top: 10; width: 200px; height: 200px;" />
That’s pretty much it. The parser takes care of the rest. It gets the address of the object from the title attribute, and the type of the object and the view from the class name. I’m using the style attribute to determine where the object container should be placed on the page. I also had to prefix the class name with "Object_" to give the parser a way to differentiate object containers from regular DOM elements. (By the way, if anyone has any suggestions about better ways to structure this I’m all ears–I admit that I have never read the W3C HTML specs so I’m not entirely sure if using these attributes this way is legit. I just wanted a way that wouldn’t break HTML validators.)
What’s also cool about this is that I can use objects that live on different domains. For example if my Dad has his own server with his calendar on it, I can display the Person object that is my Dad in a container on a page on my site, and it will create a container for his calendar object, which will then go out to his server for the data. And of course my Dad can choose how his calendar object should be displayed, and the way it’s displayed on my site will be the same as it is on his, because they’re coming from the same source. I like this level of object autonomy because it puts the content provider in complete control. Of course you can still get around that because you can access the data directly in code and hand-roll a new way to look at it, but in general if somebody wants to run ads on their calendar, I think they should be able to do that no matter where it’s being displayed.
Want to know what I think is the coolest part? You can easily create new objects on the page on the fly (using the Javascript DOM), as long as you know the address. That means that you can drag objects from another control, like the Personal Data Browser Control that I sketched out a couple days ago, onto a page, and the object magically just appears, no coding involved. Dashboard widgets on steroids.
All of my Googling to this point hasn’t yielded anyone doing this sort of weird HTML-to-Javascript-to-Server-to-object-to-XSLT remoting, and I also haven’t been able to find much on getting objects to display themselves, either (there seem to have been some attempts on fat clients, but not in browsers that I’ve been able to find). So I seem to be in new territory here and if anyone has any comments or ideas for improvements I’d love to hear them.
