Silverlight递归地将Treeview绑定到XDocument
如何递归地将 Treeview 绑定到 XDocument，将每个 XML 元素映射到 Treeview 中的节点？
从我的角度来看，下面的代码应该可以工作（并且根据我发现的有关直接绑定的极少数帖子），但它不能：（
<sdk:TreeView ItemsSource="{Binding Path=Elements}" DataContext="{Binding Path=Data}">
<sdk:TreeView.ItemTemplate>
<data:HierarchicalDataTemplate ItemsSource="{Binding Path=Elements}">
<StackPanel Orientation="Vertical">
<TextBlock Text="{Binding Name}"/>
</StackPanel>
</data:HierarchicalDataTemplate>
</sdk:TreeView.ItemTemplate>
</sdk:Treeview>
数据是父母 DataContext 上类型 XElement 的属性）
我是否在某处犯了错误或我真的需要实现 IValueConverter 才能获取 XElement 的子元素吗？
How can I recursivly bind a Treeview to an XDocument, mapping each XML Element to a Node in the Treeview?
The code below should work from my perspective (and also according to the very few posts I found regarding direct binding), however it does not:
<sdk:TreeView ItemsSource="{Binding Path=Elements}" DataContext="{Binding Path=Data}">
<sdk:TreeView.ItemTemplate>
<data:HierarchicalDataTemplate ItemsSource="{Binding Path=Elements}">
<StackPanel Orientation="Vertical">
<TextBlock Text="{Binding Name}"/>
</StackPanel>
</data:HierarchicalDataTemplate>
</sdk:TreeView.ItemTemplate>
</sdk:Treeview>
(Data is a Property of type XElement on the parents' DataContext)
Did I make a mistake somewhere or do I really need to implement an IValueConverter just to get at the child elements of an XElement?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
“Elements”成员不是属性，而是方法调用。
您无法绑定到 Silverlight 中的方法调用。
如果你真的一心想让这个场景发挥作用，我可以看到你有两个选择：
1. 使用 IValueConverter 提取“Elements”方法的内容。
2. 将 XDocument 包装在适当的层次结构中的托管类中。
就我个人而言，虽然选项 1 似乎是最快的，但我相信从长远来看，它会花费您更多的时间来维护和支持，而不是额外花费 10 分钟构建适当的域模型。
此致，
——贾斯汀·安吉尔
The "Elements" member is not a Property, It's a Method call.
You cannot bind to method calls in Silverlight.
If you're really bent on getting this scenario to work you've got 2 options I can see:
1. Use an IValueConverter to extract the contents of the "Elements" method.
2. Wrap the XDocument in managed classes in a proper hierarchy.
Personally, While option #1 seems the fastest, I believe that in the long run it'll cost you more time to maintain and support then spending an additional 10 minutes building a proper domain model.
Sincerely,
-- Justin Angel