ALE Hangover 
May 5th, 2006
The always interesting Ross Dargahi from the Zimbra team recently released a draft specification for something they call AJAX linking and embedding (ALE), which is loosely based on the Windows object linking and embedding. They say that there are two key enabling browser capabilities for ALE. The first capability is “design mode”, which many of you web heads know can be used to specify that certain DOM nodes are actually editable in the browser; this of course is what gives us wonderful Web 2.0 goodness such as Writely. Second, they suggest the use of IFRAMEs as a component sandbox.
At first glance these seem quite pragmatic and give us some powerful tools for creating composite AJAX applications such as mash-ups or (in the interests of Zimbra) documents. That being said I also have some constructive criticism to offer. The first thing that comes to mind is why the need for using design mode to edit content? There are many rich AJAX components out there that do not require design mode to enable editing and in fact using it would likely be a hinderance. I could certainly see the usefullness of having a designMode property on an AJAX component just to notify a component when it should be in an editable state. There are of course a few cases where design mode is quite necessary (like the afformentioned Writely rich text editor), however, that is pretty much the only significant case that design mode is of use. For structures such as trees or spreadsheets, design mode is just not useful. Don’t get me wrong here, I am not suggesting that there is no need for rich online content creation, we just don’t necessarily need to use design mode to achieve it.
As for IFRAMEs, personally I don’t want my rich AJAX components to be confined to one square of screen real estate. The DOM API of a web page is quite a unique and powerful abstraction relative to more traditional user interface paradigms such as Windows Forms, to limit DOM usage to small squares of rich user-interface would be rather draconian. Having said that, when you start building web applications that look and feel much more like desktop applications then it may not be all bad. But then again, the AJAX community is in some ways forcing the desktop to be more like the web, not the other way around 
In general an OLE like idea is easily achieved on the web since the entire web page DOM is essentially a rich editor sandbox and linking is easily achieved by including resouces (JavaScript, CSS, images etc) over HTTP. So without using IFRAMES or design mode I think it is safe to say that AJAX is OLE ready. Having not come from a Windows OLE type background I have started to look into the concepts a bit more on MSDN to see what we can take away.
I think that the most important point that Ross form Zimbra makes is that we do need to define some object interface that allows one to instantiate and (de)serialize an AJAX component in a standard way. One big thing missing though is a standard way of getting data into and out of an AJAX component; I think that is the really important piece of functionality that OLE brings to the table. That could mean either copying data from one AJAX component to another or from an AJAX component to a desktop application. I want to be able to select a sweet Google financial graph, press ctrl+c (or maybe apple+c) and then be able to paste that data in my AJAX Spreadsheet. Esentially, as Ray Ozzie pointed out, we need a common Web Clipboard - clipboard is a critical part of OLE or ALE. We have been using pretty much this same technique with our products to copy data from Microsoft Excel to an Nitobi Grid AJAX component and vice-versa.
There are also other kinds of data sharing (like drag-and-drop) and interfacing that need to be standardized to make some really kick-ass mash-ups I think. Microsoft Sharepoint, despite its faults, has some cool and fairly easy run-time connecting of components. Too bad it’s Sharepoint though 
.
Another interesting dimension of ALE is declarative AJAX. Serialization and deserialization of a component with its data and metadata is very important. We take the approach of defining AJAX components declaratively in a web page which is essentially using a serialized object to build the applicaiton from. This will be key and is the way things are going with XForms (W3C), XUL, XAML (Microsoft) and MXML (Adobe Flex). All this has me thinking more about microformats too … hmmmm.
I will say a bit more about what we can learn from OLE, declarative AJAX and clipboard soon!
Entries (RSS)
and