Wes is lamenting the lack of a formal doc/view framework in Avalon... I can say that as of today we don't have plans (at least on the Avalon team) to produce a doc/view framework ala MFC (as with all statements about products these are subject to change at any time, especially with feedback <G>).

A couple key points that Wes makes:

"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 the infrastructure code came for free."

However, he continues, we took a step back in WinForms:

"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."

Genghis creator Chris Sells (who is now a 'softie) often gives me grief for our decision not to do a doc/view framework.

At this point, it is all about resources. In Avalon we are rebuilding the core infrastructure for the presentation platform in Longhorn. We have a new driver model[1], graphics stack, control library, and application model. All of this with a unified approach allowing for integrated documents, ui, and media. This has been an amazing undertaking. Prior to PDC 2003 we had already spent over 2 years working on Avalon.

The issue is that we don't have enough time or resources to do everything, and right now the doc/view framework has fallen off of our plate (it was considered).

I've talked with people from the C++ team (that own MFC) and the .NET Client team (that own WinForms) to see if they have the resources to build a doc/view framework on top of Avalon. The nice thing about a doc/view framework (going the way that MFC did) is that it can be layered on top of a core framework. No news yet as to if they can or will do it, but we are listening to the feedback and trying to understand how we could tackle this.

"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."

I've spent a small amount of time programming in Objective C against Cocoa, and I also found it very elegant, but overly complex to do simple tasks. My personal believe is that MVC paradigms should always be layered on top of a simple object oriented component based framework. There is a large class of developers that don't understand MVC and you can never hide complexity completely.

"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."

I disagree with your view here, but I totally understand the concern. Right now we are trying to crawl before we run. Avalon has a complete editing infrastructure with extensible mechanisms for adorners, backend stores, selection, etc. With a couple simple controls and properties you can create a editing surface for writing documents, media (animations, vector graphics, etc.), and ui (traditional forms). While we do lack the doc/view framework as an intrinsic, we are spending a lot of time trying to make sure that the platform provides the core services to allow for a great document editor...

[1] All WinXP drivers will continue to be supported, rather there is a new driver model that will be more robust, blah blah...