Document-based Applications in Avalon

One of my hopes in Longhorn is that it becomes truly easy to write a traditional document-based application (like Word, Excel and Visio), just as in MFC. (The Microsoft developers have been asking developers for feedback on the whole Avalon API; well, here is mine!!)

In MFC, we start with a full implementation of a document-based application that does nothing; all the infrastructure (opening, edit, printing, windowing, OLE, etc) is in place, and developing an application involves simply modifying the do-nothing application to do something. The best thing about this approach was that almost all the testing for the infrastructure code came for free.

In WinForms, we lost that, although there is a project underway called Genghis to restore the missing glue tying all the framework objects together into a document-based application.

I am hoping that it will come back with Avalon; it's just not clear at this point. There is an entire team focused on creating the application model, but, from studying the PDC presentations and other Avalon material both in and out of Microsoft, it seems that Microsoft is primarily focused on web-like navigation-based applications. I've also heard from sources some traditional controls, like the toolbar won't even be available, because of schedule restrictions and the fact that their functionality can be duplicated to some degree with other Avalon panels, but I doubt that these panels can duplicate the floating windows capability, dynamic docking, or the chevron button for undersized toolbars.

I could also point to a few features from WinForms that will probably not be supported at all in Avalon, like MDI (multidocument interface). Because of the way Avalon is architected, it is not designed to support windows inside windows well, although some support exists so that legacy Win32 and WinForms controls can be hosted within an Avalon window. Longhorn introduces a second type of window (incompatible with traditional Win32 windows), called a MIL hwnd, that utilizes DirectX and does not support GDI rendering.

On the other hand, many Avalon APIs are still in development and not currently in the Longhorn SDK. One of the user experience documents, Application Archetypes, actually documents about nine difference classes of applications, (one of which is Document Editor Applications), which leads me to think there will be some consideration for each class of Application in Avalon. There are also some indications from obscure classes in the System.Windows namespace that new document editing capabilities support are forthcoming with classes like Command, Undo, and Document.

One thing clear to me is that Avalon framework is very different from other object-oriented frameworks. I have seen or used quite a number of frameworks in the past such as OWL, VCL, MFC, MacApp, and TCL.

Traditional frameworks usually adopt a Model-View-Controller (MVC) model from Smalltalk, for example. They often include a command routing mechanism that dispatches messages to a chain of objects until one object accepts responsibility for the command.

Depending on how you look at Avalon, these paradigms may or may not be present.

The first version of Avalon had an overly complicated Model-Presenter-View paradigm, with two trees; the current version simplifies this by removing the Presenter and merging the Model and View into, I believe, a single tree which can be view independently as either a logical tree of nodes or a visual tree. (I had initially believed that two trees were maintained in current version, but Chris Anderson, Avalon program manager indicated otherwise in a post.) The visual tree view, even in this single tree, can be changed independently of the logical view. If you asking yourself, "Huh?" you know what exactly what I feeling.

As for command-routing, elements (the Model part of Avalon's framework) support .NET events. If you are used traditional frameworks, you may be disappointed by the use of these events. However, though these events look like .NET events and act like .NET events, Avalon elements have custom add and remove handlers events that utilize the RoutedEventID object to manage events and perform routing such as tunneling (passing events to children) and bubbling (passing events to parent elements). After looking at the PDC presentations on the "New UI Automation Framework" and "Keyboard, Speech and Pen Input in Your Controls,” the event mechanisms appear to be more flexible than I originally thought.

I was looking at the Cocoa documentation for Apple's OS X, which does provide a document-based application infrastructure. Based on the NextStep API, it's the closest thing to the WinFX in Apple's arsenal. It can be used by Objective C, which has a funky syntax derived from SmallTalk. It can also be accessed by Sun's Java, Apple's answer to C#.

Other than the strange Objective C syntax, I found much to my liking in Cocoa. I was surprised to see support for name-value pairs, which look similar to Dependency Properties in Avalon. Cocoa does use the familiar MVC paradigm, with the standard NSController, NSApplication, NSDocument, NSWindow, NSControl objects. NSWindow, NSApplication and other "NSViews" derive from NSResponders, which implements the "Chain of Responsibility" design pattern. Even though, I have never seen Cocoa before, I know how it works because it follows the same pattern as every other framework. I know that Cocoa's NSResponder is the same as TCL's Bureaucrat, which is the same as MacApp's EventHandler.

Not so with Avalon. Microsoft just had to make Avalon different. This is not necessarily a bad thing. This are some positive aspects about Microsoft's approach.

The approach to creating a new document is to derive new FrameworkElements (or ContentElements) and create new DependencyProperty's. Most of the data structure management work is already taken care of; for example, serialization and undo are almost free. Elements themselves can be constructed very easily in a number of ways--the #1 way being element composition. Building a new wordprocessor is very easy, because Avalon gives unprecedented low-level control of rich text. New elements can be created over a span of text, and can alter the rendering of that text range.

With the ease of use, there are some restrictions imposed. Creating a new document-based application with elements will also likely mean that the primary format will XAML or BAML (binary XAML). I have a sense that after Longhorn ships that XAML will become the most popular document format after HTML and TEXT.

But my fear is that, while document-based applications based on Avalon may become more flashy, they will look more like web-pages and less like Office-style applications. I not getting the sense that Avalon is paying attention to the traditional document-editor application. While the document portion may be made easier to develop through elements, duplicating the Office UI will probably be much harder due to the omission of traditional controls like toolbars and MDI to name a few. I don't feel that a flashy document-editor application (written in Avalon ) will be respected as much as an Office-like application in the software marketplace.

Comments

[Gus Mueller]

You write about Apple's Cocoa frameworks:

> It can also be accessed be by Java, Apple's answer to C#.

That doesn't seem to make much sense. Java was written by Sun, and most people seem to think C# is MS's answer to Java. Apple just licenses Java from sun.