After I successfully updated the iMac (running the Tablet PC OS under BootCamp) with the latest WinFX Beta 2, Windows SDK Beta 2, and so on, I had another day of XAML programming.
Most of my XAML toy apps are up and running again just fine. The more “complicated” apps are another matter. I simply don’t know enough about all the permutations of the increasingly important data binding and “template” models.
I understand the goal that XAML isn’t intended to be a full programming language, but what it is is a bit confusing to me at times. I don’t have a sufficient model in my head that says “so-and-so goes in XAML” and “this-kind-of-stuff goes in codebehind.” Simple XAML apps are one thing. More complicated apps are another. It’ll come in time, but I’m realizing at times like this that it isn’t there.
To me, it looks like XAML keeps wanting to be a complete programming language. But that’s because I don’t get it completely. I know I don’t. My head keeps zooming ahead wanting to do more. When I start coding in XAML, I just want to do things there.
Here’s a nonsensical and incorrect XAML statement that paradoies my lack of understanding. To me, I’d almost expect XAML to have a “DoIt()”-like functional equivalent that looks like:
(Yes, this is a bad coding joke. Don’t worry this is not XAML. It’s just me poking fun at my mind.)
Of course, this gets to looking mighty messy–at least to a human. I haven’t thought through at all whether the binding, resources, and so on would look clean to a computer. I bet that’s mighty important in a language like XAML.
Well to understand XAML you need to throw away the notion that it has anything to do with WPF because it doesn’t. XAML is to WPF as C# is to Windows Forms. XAML is just a markup language that allows you to build complex object hierarchies declaratively. When you think of XAML, you should think of it as a way to instantiate objects, set their properties, and create child objects. After all, XAML is used with Windows Workflow Presentation and technically could be used with ASP.NET which of course did basically the same thing as XAML but specifically for web.
So then the question is what is attributes and what is behavior? Behavior should be done in code-behind, but the line is a little blurry in WPF. For example, when you invoke triggers, this is represented in XAML but it would seem like an “action”. I like to think that the changing of attributes on a timeline is more “attribute” than “behavior”.
But we’re all still new at this so it’ll take a while to get into the groove.
The line between “attributes” and “behaviors” will become more obvious over time as you point out as you point out.
An ad hoc definition might be: Anything that can be declared in XAML is an attribute and the rest are behaviors 🙂
I think my years of Prolog programming are messing with my mind when it comes to XAML. I keep wanting to declare conditionals or relations or stick in functions where they don’t belong.
For instance, sometimes I get tripped up wanting to bind on multiple values that are dependent upon one another (such as determining the best fit in width and height of an item). I can make a simple declaration that defines the relationship, but I don’t know how to or if it’s possible or if it’s XAML-ethical to want to place this declaration somewhere in the XAML statements.
At a crude level I keep thinking of:
which I’d expect to display a textbox with the value of 12 in it.
or in a little more complicated fashion maybe display in the textbox the width of the textbox divided by 4 that gets re-evaluated as any dependent item in the expression changes (in this case the width).
or maybe in the binding syntax, maybe define a template with the relation in it.
There are lots of examples along these lines: Declaring how a string is to be filtered, displaying one string versus another based on one or more relations, and so on.
Sometimes the solution requires thinking in a different way. And sometimes I have to remember to forget. 🙂