XAML 解析器如何识别 NameScopes? [英] How does a XAML parser identify NameScopes?

问题描述

在 XAML 解析的上下文中，我想知道解析器如何知道类型何时定义了 NameScope.

In the context of XAML parsing, I would like to know how does the parser know when a type defines a NameScope.

是否完全依赖INameScope接口，检查instance is INameScope?

Does it rely entirely on the INameScope interface, checking instance is INameScope?

它是否依赖于布尔属性 XamlType.IsNameScope?

Does it rely on the boolean property XamlType.IsNameScope?

两者兼而有之吗?

推荐答案

Microsoft 文档对此有一些很好的信息:

The Microsoft documentation has some good information on this:

默认情况下，当由 .NET Framework XAML 服务 API 使用时，主要 XAML 名称范围在单个 XAML 产品的 XAML 根元素中定义，并包含该 XAML 产品中包含的元素.

By default when used by .NET Framework XAML Services API, the primary XAML namescope is defined at the XAML root element of a single XAML production, and encompasses the elements that are contained in that XAML production.

这里的要点是任何 Xaml 文档中的根元素都有一个为其创建的名称范围.这种情况不管元素是否实现了INameScope(事实上，没有核心 UI 元素实现).

The takeaway here is that the root element in any Xaml document has a name scope created for it. This happens regardless of whether the element implements INameScope (and, in fact, no core UI elements do).

框架可以定义可能出现在单个 XAML 产品中的其他离散 XAML 名称范围，以解决特定情况.例如，在 WPF 中，新的 XAML 名称范围由同样在该 XAML 产品中定义的任何模板定义和创建.有关 XAML 名称范围(为 WPF 编写但与许多 XAML 名称范围概念相关)的详细信息，请参阅 WPF XAML 名称范围.

Additional discrete XAML namescopes that might occur within a single XAML production can be defined by frameworks to address specific scenarios. For example, in WPF, new XAML namescopes are defined and created by any template that is also defined on that XAML production. For more information about XAML namescopes (written for WPF but relevant for many XAML namescope concepts), see WPF XAML Namescopes.

除了为根元素创建的名称范围之外，还会为 Xaml 产品中定义的任何模板隐式创建名称范围.这应该不足为奇，因为 FrameworkTemplate 实现了 INameScope，因此 DataTemplate 和 ControlTemplate 也是如此.还为 Style 元素创建了名称范围.

In addition to the name scope created for the root element, name scopes are implicitly created for any template defined within a Xaml production. This should not be surprising, as FrameworkTemplate implements INameScope, and thus so do DataTemplate and ControlTemplate. Name scopes are also created for Style elements.

您可能注意到 ResourceDictionary 也实现了 INameScope，但它有点极端:资源字典中的对象名称​​实际上 在任何运行时名称范围内注册.如果查看实现，您将看到它的 INameScope 方法要么抛出 NotSupportedException，什么都不做，要么返回 null.这种设计很好地保留了名称.它们被阻止在任何父作用域中注册，同时使它们可用于有限的目的，例如在 Binding 上使用 ElementName 引用.重申一下，作为名称范围的资源字典是一种边缘情况，实际上，您永远不必考虑.

You may notice that ResourceDictionary also implements INameScope, but it is a bit of an edge case: names of objects in a resource dictionary are not actually registered in any runtime name scope. If you look at the implementation, you will see that its INameScope methods either throw a NotSupportedException, do nothing, or return null. This design keeps the names nicely contained. They are prevented from being registered in any parent scope, while making them available for limited purposes like using an ElementName reference on a Binding. To reiterate, resource dictionaries as name scopes are an edge case that, practically speaking, you should never have to think about.

除了上述隐式创建的范围之外，还为任何对象创建节点的 Xaml 解析器框架创建了一个新的名称范围，其中创建的对象实现了 INameScope.与所有名称范围一样，注册名称在该范围内必须是唯一的；但是，它们可能会与堆栈中其他名称范围内的名称发生冲突.

Beyond the implicitly created scopes outlined above, a new name scope is created for the Xaml parser frame of any object creation node where the created object implements INameScope. As with all name scopes, registered names must be unique within that scope; they may, however, collide with names in other names scopes further up the stack.

从 Xaml 实现对象时，XamlObjectWriter 通过在堆栈中向上查找具有名称范围的帧来解析名称，一旦找到包含所需名称的范围就停止.例如，当评估来自 x:Reference 指令的延迟引用时，就会发生这种情况.

When materializing an object from Xaml, the XamlObjectWriter resolve names by walking up the stack looking for frames with name scopes, stopping once it finds a scope containing the desired name. This would happen, for example, when evaluating a deferred reference from an x:Reference directive.

是否完全依赖于INameScope 接口，检查instance is INameScope?
它是否依赖于 boolean 属性 XamlType.IsNameScope?

Does it rely entirely on the INameScope interface, checking instance is INameScope?
Does it rely on the boolean property XamlType.IsNameScope?

通常是后者，但该标志是通过确定类型是否可分配给 Xaml INameScope 类型来设置的，该类型映射到 System.Windows.Markup.INameScope.它不检查运行时实例，而是检查相应对象创建节点的 XamlType.从概念上讲，该检查类似于 typeof(INameScope).IsAssignableFrom(instanceType).

Generally the latter, but that flag is set by determining whether a type is assignable to the Xaml INameScope type, which maps to System.Windows.Markup.INameScope. It does not check the runtime instance, but rather the XamlType of the corresponding object creation node. Conceptually, the check is similar to typeof(INameScope).IsAssignableFrom(instanceType).

虽然你没有问，但为了完整起见，我想说明最后一点:

Although you didn't ask it, I'd like to address one final point for the sake of completeness:

对象何时注册到名称范围?

When is an object registered in a name scope?

这在两种情况下发生:

1. 您在 Xaml 元素上显式设置了 x:Name 伪属性；
2. 您设置了一个类似于 FrameworkElement.Name 的属性，它被定义为一个运行时名称属性.

1. You explicitly set the x:Name pseudo-property on a Xaml element;
2. You set a property like FrameworkElement.Name, which is defined as a runtime name property.

像 FrameworkElement 这样的类型有自己的 Name 属性，而不是强迫开发人员指定 Name 和 x:Name 分开，他们提供了一种将 CLR 属性映射到 x:Name 的方法.如果您查看 FrameworkElement 的源代码，您将看到一个 [RuntimeNameProperty("Name")] 属性.这告诉 Xaml 基础结构任何 FrameworkElement 上的 Name 属性对应于 x:Name，并且设置一个应该导致设置另一个以及.请注意，运行时名称属性可以具有任何有效名称；它不需要被称为Name.

Types like FrameworkElement have their own Name property, and rather than forcing developers to specify Name and x:Name separately, they provided a way to map the CLR property to x:Name. If you look at the sources for FrameworkElement, you will see a [RuntimeNameProperty("Name")] attribute. This tells the Xaml infrastructure that the Name property on a any FrameworkElement corresponds to x:Name, and setting one should result in the other being set as well. Note that the runtime name property can have any valid name; it needn't be called Name.

这篇关于XAML 解析器如何识别 NameScopes?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！