Interesting post from Charles Petzold about why he structured his book Applications = Code + Markup they way he did: with code-based examples first and then XAML-based examples towards the end.
When I read the book, I immediately remarked on the structure and wondered several times while reading it whether or not it made sense the way he did it. I found his article very helpful in explaining why:
The more I explored XAML on my own, the less I seemed to know. How do panels work? Why were some properties bindable but others were not? Why were some properties animatable but others were not? Why do those properties called “attached properties” seem to be in the wrong place? Why can you specify an event handler for children in a parent’s tag? What happens when modifying an existing control with a template isn’t enough and you need to write a custom control with keyboard and mouse handling and drawing?
Of course, answering these questions for myself required a lot of exploration. XAML is not as simple as it first seems. XAML required a whole intrastructure in WPF that involves layout mechanisms, dependency properties, routed events, and other features. It became quite obvious that most WPF programmers would want a familiarity with this infrastructure. Most WPF programmers would also want to gain a facility for working with this infrastructure. This can only be achieved in code.
Just one example: If you see an attached property in XAML — such as Grid.Row=”2” — it really doesn’t make a lot of sense. You’re specifying a property of the Grid panel within a child element of the Grid. If you look at the syntax in code, however, and you’re given an explanation of what’s going on behind the scenes in the context of alternative syntax, then attached properties make perfect sense.
I made a decision to tackle a lot of the WPF infrastructure very early in the book. I have an early chapter on dependency properties and a chapter on routed input events. I show how to write custom elements and custom panels comparatively early in the book. Many of my sample programs contain Window constructors that create and intialize elements and controls, which is a job that is eventually taken over by XAML, but doing it in code is something that every WPF programmer should know. Some stuff — such as defining a template — is incredibly painful in C#, but my book shows examples of that as well, and I hope the reader later comes to appreciate the relative simplicity of doing it in XAML.
He also gives a hint at a WPF feature that never saw the light of day:
I kept a close eye on one very special feature: the ability to embed C# code in a stand-alone XAML file and have it run in the browser. Although this feature was hinted at a bit, it never became real. If it had become real, I might have gone this route — or at least seriously considered it.
Is this where the WPF/E mini-CLR comes in?
Posted in Uncategorized
Tags: Microsoft
Shebanator 