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？

没有XAML属性列表？

    SDK并不是真的有一个“所有权页面”，这是XAML特有的。你可以把property列表看作是普通的成员表的一部分，但要选出XAML属性有点困难，因为有些是只读的，有些又不使用支持XAML的类型，等等。这里，我想我们不得不承认工具和设计者可以比只利用SDK的成员表做得更好。因为工具和设计者有语义的优势；他们知道你刚刚实例化了什么面板子类，在元素树里面它处于什么位置等。好好地综合基于工具的只列出基本的可能性的智能，然后学会按F1来获取SDK页面的更多的帮助信息。这是我们追赶即将来临的工具/SDK的发行的下一步。限于篇幅，不能细细讲解。

没有XAML XSD的计划？

    我以前在博客上写过这个。对一个像WPF这样有很多维的产品来说，XAML的计划很困难。但你也许已经注意到接下来的XAML综合技术（Workflow Foundation, Silverlight）确实包括了XSD类型的计划。说到WPF XAML的计划，我们仍然保持观望。