Caliburn.Micro：将已按约定绑定的按钮文本绑定到方法
我正在使用 Caliburn.Micro 出色的基于约定的绑定将按钮绑定到我的视图模型上的方法。问题是，我希望按钮的 Content 绑定到视图模型的 string 属性。
目前，我允许方法的约定绑定和内容的显式绑定。这是一个例子：
例如：
<Button x:Name="Submit" Content="{Binding SubmitCaption}" />
public class MyViewModel : PropertyChangedBase
{
public void Submit() {}
public string SubmitCaption { get; set; } // Technically would raise PropertyChanged event
}
但是我想知道是否有更优雅的方法来做到这一点？我正在考虑重写按钮的约定，以便它仍然将按钮操作绑定到方法，但将内容绑定到按约定命名的属性。
<Button x:Name="Submit" />
public class MyViewModel : PropertyChangedBase
{
public void Submit() {}
public string SubmitContent { get; set; } // Technically would raise PropertyChanged event
}
I'm using Caliburn.Micro's excellent convention-based binding to bind a button to a method on my view model. Thing is, I want the Content of the button to be bound to a string property of the view model.
At the moment I'm allowing the convention binding for the method, and an explicit binding for the content. Here's an example:
E.g.:
<Button x:Name="Submit" Content="{Binding SubmitCaption}" />
public class MyViewModel : PropertyChangedBase
{
public void Submit() {}
public string SubmitCaption { get; set; } // Technically would raise PropertyChanged event
}
However I was wondering if there's there a more elegant way of doing this? I'm thinking about overriding the convention for buttons so that it still binds the button action to a method but the content to a named-by-convention property.
<Button x:Name="Submit" />
public class MyViewModel : PropertyChangedBase
{
public void Submit() {}
public string SubmitContent { get; set; } // Technically would raise PropertyChanged event
}
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您可以自定义所有按钮的默认行为，但我认为您当前的方法对开发人员来说更加明确和明显，并且看起来并不是特别令人讨厌。我建议坚持你所拥有的。
如果您决定希望
Button内容不仅仅是一个字符串，会发生什么？您是否将SubmitContent设置为对象类型？你会在代码中设置它的值吗？这对我来说听起来更恶心。You could customise the default behaviour for all buttons, but I think your current approach is more explicit and obvious to developers, and doesn't seem particularly nasty. I would recommend sticking with what you've got.
What happens if you decide you want the
Buttoncontent to be more than a string? Do you makeSubmitContentan object type? Would you set its value in code? That sounds nastier to me.