The Avalon rearchitecture that happened earlier this year was motivated by several things (in my mind... hmm... another time for a disclaimer - as with anything that happens each participant will have a slightly different version of the "truth". As time goes their becomes more and more difference between each persons view. So, all that follows here is my fuzzy recollection of what happened, and shouldn't be missinterpreted to be the only "truth" of what happened...)...

• Simplicity
• Performance
• Flexibility

Before I start, I need to tell you about a few new names - DOTNET and WCP. Our old architecture bits lived in a source tree where the root name was "DOTNET". I wasn't on the team when this name was choosen, but I'm guessing that it was picked because the Avalon team was an early adopter of managed code, and so they named the directory after .NET. When we began work on the new architecture we picked a new directory name, "WCP". When I refer to WCP and DOTNET design, these are nothing more than the names of two directories in our build tree - these aren't product names, no warrenties apply, blah blah...

Simplicity

The DOTNET model had some pretty severe problems with complexity of the design. Their tended to be 7 ways to do anything, and many of them tended to be massively complex. The reason for this was pretty simple - we had 400 people working on the product and all of them were trying to build the "best" of whatever they were working on. The best example that I have is how to customize the appearance of your control... we had templating, presenters, element composition, visuals, etc... I can't remember the complete list, but at one point there were actually 7 full featured ways to customize this.

Probably the most maligned peice of technology in DOTNET was this thing called "Presenters". Presenters were a very well thought out, robust, and complete technology. Basically it was an abstraction over layout and rendering, which allowed for any control to have any display. Presenters allowed for pluggable rendering, pagination, virtualization, etc. They allowed for a clean separation between the visual tree and the element tree.

Ah, which reminds me - we had a lot of trees at the time. There was the element tree which was where your buttons and listboxes lived, and the visual tree which was the retained mode managed scene graph, the presenter tree which was a "kinda" tree that was made up of the presenters and their relationships  to their child presenters (basically an element may or may not have an element. For example, text formatting elements like "Bold" didn't have a presenter, they used their parent presenter), and we had a composition tree, etc.

Presenters where this great thing, however they were very complex to use, and they had a fairly different design center and programming model than the rest of the system.

Our solution to simplify a lot of this in WCP was to make a couple big bets - Element composition and a unified tree.

Where in DOTNET we had a separate tree for elements, visuals, and presenters - in WCP we have a single tree of nodes. For various reasons we have multiple "views" on the tree - Logical and Visual - they actually share nodes. Some people find this 1.5 tree system to also be confusing and we are still looking at ways to simplify this.

Element composition was the biggest bet by far. We are now using elements for all display composition. When you see a button in the PDC build, there are actually 17 elements inside of that button. Rectangles, Borders, DockPanels, Text, etc. Using a single feature for all rendering allowed us to remove some of the duplicate ways of customizing the display of the elements. In addition, we settled on a single styling system that included the ability to style the "visual tree" of any element.

To be continued...