Questions tagged «xaml»

1
为什么.Net世界似乎包含魔术字符串而不是静态类型的替代字符串?
因此,我在.Net中工作。我在.Net中制作开源项目。我最大的问题之一不是.Net的必要性,而是它周围的社区和框架。似乎到处都有神奇的命名方案和字符串被视为做所有事情的最佳方法。大胆的声明,但看看它: ASP.Net MVC: 您好世界路线: routes.MapRoute( "Default", // Route name "{controller}/{action}/{id}", // URL with parameters new { controller = "Home", action = "Index", id = "" } // Parameter defaults ); 这意味着ASP.Net MVC将以某种方式HomeController在您的代码中查找。以某种方式创建它的新实例,然后Index 显然使用某种id参数调用该函数。然后还有其他类似的东西: RenderView("Categories", categories); ...or.. ViewData["Foobar"]="meh"; 然后XAML也有类似的事情。DataContext被视为一个对象,您必须希望并祈祷它可以解析为所需的类型。DependencyProperties必须使用魔术字符串和魔术命名约定。像这样的事情: MyData myDataObject = new MyData(DateTime.Now); Binding myBinding = new Binding("MyDataProperty"); myBinding.Source = …

10
在什么条件下使用MVVM是合适的?
模型视图视图模型是由Microsoft开发的,目标是支持事件驱动编程的UI开发平台,特别是使用XAML和.NET语言的.NET平台上的Windows Presentation Foundation(WPF)和Silverlight。此后的几年中,许多Javascript框架(例如Angular,Knockout和ExtJS)都采用了这种模式。 像大多数软件模式一样,MVVM具有适当的用途和滥用。在什么条件下使用MVVM是合适的?什么时候不明智?

5
价值转换器会带来更多麻烦吗?
我正在使用需要大量值转换的视图的WPF应用程序。最初,我的哲学(部分是受到有关XAML信徒的激烈辩论的启发)的,我应该严格按照支持视图数据要求的观点来构建视图模型。这意味着将值转换为可见性,画笔,大小等所需的任何值转换都将由值转换器和多值转换器处理。从概念上讲,这似乎很优雅。视图模型和视图都将具有独特的目的并且可以很好地分离。在“数据”和“外观”之间将划清界限。 好吧,在将这种策略赋予“旧的大学尝试”之后,我有些怀疑是否要继续以这种方式发展。我实际上正在强烈考虑转储值转换器,并将(几乎)所有值转换的责任直接交给视图模型。 使用价值转换器的现实似乎并没有达到完全分开的关注点的表观价值。对于价值转换器,我最大的问题是使用它们很乏味。您必须创建一个新类,实现IValueConverter或IMultiValueConverter,将一个或多个值转换为object正确的类型,进行测试DependencyProperty.Unset(至少对于多值转换器而言),编写转换逻辑,在资源字典中注册转换器 [请参见下面的更新],最后,使用相当冗长的XAML(这要求转换器的绑定和名称都使用魔术字符串)来连接转换器[请参见下面的更新]。调试过程也不是一件容易的事,因为错误消息通常是不明确的,尤其是在Visual Studio的设计模式/ Expression Blend中。 这并不是说替代方案(使视图模型负责所有值转换)是一种改进。这很可能是另一面草更绿的问题。除了失去优雅的关注点分离之外,您还必须编写一堆派生属性,并确保RaisePropertyChanged(() => DerivedProperty)在设置基本属性时认真调用,这可能会带来令人不愉快的维护问题。 以下是我汇总的初始清单,这些清单允许视图模型处理转换逻辑并取消使用值转换器的优缺点: 优点: 由于取消了多转换器,因此总绑定数更少 较少的魔术字符串(绑定路径+转换器资源名称) 无需再注册每个转换器(还要维护此列表) 减少编写每个转换器的工作(无需实现接口或强制转换) 可以轻松注入依赖项以帮助进行转换(例如颜色表) XAML标记不那么冗长,更易于阅读 转换器重用仍然可能(尽管需要一些计划) DependencyProperty.Unset没有神秘问题(我在多值转换器中注意到的一个问题) *删除线表示如果您使用标记扩展,这些好处将消失(请参阅下面的更新) 缺点: 视图模型和视图之间的耦合更强(例如,属性必须处理可见性和画笔之类的概念) 更多的总体属性可允许直接映射视图中的每个绑定 RaisePropertyChanged必须为每个派生属性调用(请参阅下面的更新2) 如果转换基于UI元素的属性,则仍必须依赖转换器 因此,正如您可能会说的那样,我对此问题感到非常沮丧。我非常不愿走重构的道路,只是意识到无论我在视图模型中使用值转换器还是暴露大量的值转换属性,编码过程都是同样低效而乏味的。 我是否缺少任何利弊?对于那些尝试了两种价值转换方式的人,您觉得哪种对您更好,为什么?还有其他选择吗?(门徒提到了有关类型描述符提供程序的一些内容,但是我无法理解他们在说什么。对此的任何见解都将受到赞赏。) 更新资料 我今天发现,可以使用一种称为“标记扩展”的东西来消除注册值转换器的需要。实际上,它不仅消除了注册它们的需要,而且还提供了在您键入时选择转换器的智能感知Converter=。这是让我入门的文章:http : //www.wpftutorial.net/ValueConverters.html。 使用标记扩展的能力在上面我的优缺点列表和讨论中(见删除线)在某种程度上改变了平衡。 作为这个启示的结果,我正在尝试一个混合系统,在该系统中,我将转换器用于BoolToVisibility我所说的内容MatchToVisibility,并将视图模型用于所有其他转换。MatchToVisibility基本上是一个转换器,可以让我检查绑定值(通常是枚举)是否与XAML中指定的一个或多个值匹配。 例: Visibility="{Binding Status, Converter={vc:MatchToVisibility IfTrue=Visible, IfFalse=Hidden, Value1=Finished, Value2=Canceled}}" 基本上,这是检查状态为已完成还是已取消。如果是,那么可见性将设置为“可见”。否则,它将设置为“隐藏”。事实证明,这是非常普遍的情况,使用此转换器可以为我节省约15个属性(以及关联的RaisePropertyChanged语句)。请注意,当您键入时Converter={vc:,“ MatchToVisibility”将显示在智能菜单中。这显着减少了出错的机会,并减少了使用值转换器的麻烦(您不必记住或查找所需值转换器的名称)。 如果您感到好奇,我将在下面粘贴代码。这种实现的一个重要特点MatchToVisibility是,它检查是否绑定的值是一个enum,如果是,它检查,以确保Value1,Value2等也都是相同类型的枚举。这样可以在设计时和运行时检查是否有任何枚举值输入错误。为了将其改进为编译时检查,您可以改用以下代码(我手动输入了此代码,因此,如果我有任何错误,请原谅我): Visibility="{Binding Status, Converter={vc:MatchToVisibility IfTrue={x:Type {win:Visibility.Visible}}, …
20 silverlight  wpf  mvvm  xaml 

6
在Metro应用程序中使用XAML / C#或HTML5 / JavaScipt的优缺点?[关闭]
按照目前的情况,这个问题不适合我们的问答形式。我们希望答案会得到事实,参考或专业知识的支持,但是这个问题可能会引起辩论,争论,民意测验或进一步的讨论。如果您认为此问题可以解决并且可以重新提出,请访问帮助中心以获取指导。 7年前关闭。 我只是想知道将XAML / C#或HTML5 / JavaScript用于Metro Apps是否有主要优点或缺点。
19 c#  javascript  html5  xaml  metro 

3
事后看来,基于XML的XAML是错误的还是好的方法?
XAML本质上是XML的子集。据说将XAML基于XML的主要好处之一是可以使用现有工具进行解析。尽管(语法上不重要的)属性值将保持文本形式并需要进一步解析,但它在很大程度上可以。 用XML派生的语言描述GUI有两种主要选择。一种是做WinForms所做的事情,并用真实的代码对其进行描述。尽管它并非完全没有优势,但这样做有很多问题(将XAML与这种方法进行比较是一个问题)。另一个主要的替代方案是设计专门针对手头任务的全新语法。这通常称为领域特定语言。 因此,事后看来,作为对子孙后代的一个教训,将XAML基于XML是一个好主意,还是作为一种定制设计的领域特定语言会更好?如果我们要设计一个更好的UI框架,我们应该选择XML还是自定义DSL? 由于积极地思考现状要容易得多,尤其是社区非常喜欢的现状,因此,我将举一些示例理由说明为什么在XML之上进行构建可能会被认为是错误的。 基于XML的语言有其作用:解析起来要容易得多(核心解析器已经可用),所需的设计工作要少得多,并且对于第三方开发人员来说,替代解析器也要容易编写。 但是由此产生的语言可能会以各种方式令人不满意。这很冗长。如果更改某物的类型,则需要在结束标记中进行更改。它对评论的支持很差;注释掉属性是不可能的。XML对属性的内容有一些限制。标记扩展必须建立在XML语法的“顶部”,而不是深入和完美地集成到其中。而且,我个人最喜欢的是,如果您通过属性设置内容,则使用的语法与将内容属性设置为完全相同的语法完全不同。 也有人说,由于每个人都了解XML,因此XAML需要的学习较少。严格来说,这是事实,但是学习语法只是学习新UI框架的一小部分时间。正是框架的概念使曲线变得陡峭。此外,基于XML的语言的特质实际上可能会添加到“需要学习”的篮子中。 易于解析会抵消这些缺点吗?下一个很酷的框架是否应该延续这一传统,还是应该花时间设计出色的DSL,而DSL是现有工具无法解析的,并且每个人都需要学习其语法? PS并非每个人都对XAML和WPF感到困惑,但是有些人对此感到困惑。XAML是类似XML的东西。WPF是支持绑定,主题化,硬件加速和许多其他很酷功能的框架。
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.