XAML 语法

   SDK文档提供了XAML各种用途下的XAML语法，比如用来实例化一个XAML类的对象元素标签，用来设置属性或附带事件句柄的属性，还有XAML的具 体概念，如content property或property element语法。另一个隐藏的秘密来了...好的，也不是那么的隐秘了，因为我以前已经在博客上写过了。XAML不一定非要被绑定到计划中。最终决定 XAML是否有效的是XAML loader，最终成功还是失败取决于一些加载动作，比如试图在组件中找到一个命名匹配的类型，调用它的默认ctor，以及返回一个实例。或者，一旦对象 存在，就是试图找到一个匹配属性名字的property，然后试图用属性值的string-to-X变换，或者甚至是更复杂的在property元素中以 子关系存在的XAML的什么东西的封装来填充它。对于保持XAML的扩展性来说是有必要的，但是这会让编写文档和静态的XAML词典更困难一点儿。其一， parser会允许你实例化一个在对象模块中没有“家”的元素。比如，大多数EventArgs子类可以在XAML中建立，因为它们可以方便的拥有一个默 认ctor（加入XAML俱乐部是如此容易....）但是，然后呢？从狭义来说，XAML是UI定义上的。广义上讲，XAML是相关的对象和你希望建立的 他们的属性的任何结构的定义。你不能把EventArgs作为任何具有可疑资源收集异常的东西的子元素。这让XAML文档进退两难：这是XAML吗，或者 不是？这个困惑经常出现。一般来说，我们用具体情况来说明XAML。有什么原因让你希望用XAML来实例化这个类吗？如果有，我们会给你看一个语法。如果 没有，就像3.0的EventArgs子类一样，我们会告诉你这并不是一个典型的应用，虽然XAML loader会在和其它面向应用的对象模型完全隔离的情况下用XAML来建立一个。

    另一个秘密：虽然没有写出语法（会说这是不适用的东西），但是在frameworks中有很多支持XAML的类。一般来说，这是因为这些类来自更早的版 本，可以在整个3.0 framework中使用，因为可能合法的XAML使用率会很大。所以，为了填补空白，用户需要知道一些XAML的技巧。对初学者，读XAML and Custom Classes就可以了。当以默认的ctor和一些其它的限定来符合XAML加载器的要求时，定制的类和已有的类没什么不同的。也去看看x:Array Markup Extension中的例子吧。这个例子讲了系统名字空间和mscorlib组件，这样你就可以吧String类作为一个直接对象进行实例化。你可以外推 这些简单的概念，并做些更有用的事情。甚至设想这个场景都有点困难，但是你们是一个充满创造性的集体：让我们看看你们能做什么！描绘一些 System.Data的结构？谁知道在pre-3.0 .NET的核心部分用了多少XAML？