It’s just data

XAML Extended Attributes

I learn best when I see examples like this one.  I find it gives me insights that one rarely finds in documentation.

From this example, I gather that XAML has a specialized syntax for dealing with two argument static/shared setters, like this one.  As I have not seen this design pattern I dig further, and find that Avalon supports Dynamic Properties.  Encapsulating such properties with static methods does seem like a reasonable thing to do, and then adapting the syntax of XAML to optimize for this also seems like a reasonable next step.  Call it co-evolution at work.

But, as I said, documentation typically is not written this way.  Pity.

The next things I see is what I perceive as a deficiency of XAML and/or Avalon.  In order to make things more visually appealing, Chris added a border around these cells.  This required the addition of an XML element for each cell.

In CSS, this could have been done once:

GridPanel SimpleText { border-color: White; }

I recognize that what I am describing is slightly different than what is actually going on in Avalon.  In CSS, the equivalent of UIElement is a Box - complete with margins, borders, and padding.  In Avalon, additional objects are required to achieve a similar effect.

That being said, and independent of the syntax for describing such things, is there value in being able to factor out the style from the content?  Put another way, are all but the most trivial XAML documents destined to become as opaque as web pages which employ nested tables and spacer gifs?


We all knew that 'separation of content and presentation' thing wouldn't last...

The Microsoft position on XAML as applied to documents (thus supplanting XHTML/CSS) appears to be "You want to do what? No, don't think of this as a web page," but I'm not sure they're fooling anyone.

Posted by Dave S. at

The "official" Microsoft party line according to Chris Anderson (XAML/Avalon "Architect") is that CSS is too slow and clumsy and it's not XML either. I'm not fooled but who am I. Anyway, for more insight check out Chris Anderson's blog online @ [link]

Posted by Gerald Bauer at

Given that XAML seems to be designed for building GUIs, you should probably ask yourself why you are overriding the default presentation of the controls at all?

In the case of GUIs, the app author generally provides the "content", while the operating system provides the "style/presentation" (in the form of the user's selected theme/colour scheme) -- contrast this to the web, where the author usually provides content and style. 

The "Background" property used in those examples is an override in the same way that the style attribute in HTML is.  If you are going to use these sorts of overrides in a GUI intended for general use, you should have a very good reason -- they can screw up the accessibility of a program.

Setting both foreground and background together isn't the answer either, since any combination you can think of is going to be unreadable to some people.  The defaults are the only thing you can trust.

Posted by James at

If I make a web site and specify in my CSS file that H1 is always 200% (or 2em or 24px or whatever), that applies to my entire site.  If I make an application and have a number of similar dialogs and specify that the first line of each of them should be bold and left-justified with a 20px left margin, I would like that to apply to my entire application.  Can I do that in XAML?  (I'm honestly asking.)

I've conquered the Herculean task of enforcing GUI standards across a large-scale client/server ERP system (~2000 separate entry screens, in Powerbuilder which has no concept of datawindow inheritance or grouping).  It wasn't fun.  If I had to do that again with XAML, would my life be easier or harder?

Posted by Mark at

XAML and... Swing

Let's see. There's this new language+API. It is, in theory platform independent. It's pretty high level. Below the high-level description, it runs on top of a virtual machine. It's verbose. Some people say it will never work. Gotta be Swing, right?...

Excerpt from d2r at

My uninformed guess at why XAML doesn't (appear to) support a CSS-like mechanism for defining style externally is that it is designed to be edited in a form builder. It's significantly harder to have a visual form designer that plays nicely with externally designed stylesheets than it is to do the whole thing by dumping the style with the structure. You can see this in all "wysiwyg" HTML editors - the default editing style (the effect you get by using the toolbars and menus to apply style to blocks of text) is to dump all the presentation either in the markup directly (using b, font, etc.) or in style attributes. Any CSS editing capabilities are off in separate dialogs, and don't interact well with the other formatting options.

Posted by jgraham at

I am shocked, SHOCKED, to hear you suggest that Microsoft, a company that makes money selling developer tools, is inventing new standards that are de facto impossible to implement without the newest version of their developer tools.

Posted by Mark at

Sam,

You might check out [link] as well as [link].

Both of which were inspired by your response to Chris' original post.

Cheers,
DB

Posted by Don Box at

Avalon Styles Overlooked

Sam Ruby also was inspired by Chris Sells' XAML and Dynamic Properties post.   Sam laments Chris' use of individual Background attributes on each Border element and proposes a CSS-based alternative.   Either ChrisAn or Rob have...

Excerpt from Drew's Blog at

XAML <em>does</em> enable content/styling separation

Don Box is doing a lot of work protecting XAML from misperception and ridicule. The latest installment informs us that...... [more]

Trackback from Notes from Classy's Kitchen

at

Sam Ruby: XAML Extended Attributes

[link]...

Excerpt from del.icio.us/elzzup at

Add your comment