I am using the implementation give at Bind TextBox on Enter-key press to handle the enter key for text box.
But I am using MVVm pattern for my application. Therefore I have defined the ICommand handler in my VieModel class. I want to bind it to view.
The sample application uses
InputBindingsManager.UpdatePropertySourceWhenEnterPressed="TextBox.Text"
and I want to use
InputBindingsManager.UpdatePropertySourceWhenEnterPressed="{Binding myCommandHandler}"
instead.
Can anybody suggest what modification are required in the code?
You can go for inputbindings for a textbox. in this you can bind a Icommand object to command property ok keybindings
Here is the sample code
<TextBox Text="{Binding Firstname, UpdateSourceTrigger=PropertyChanged}">
<TextBox.InputBindings>
<KeyBinding Key="Enter" Command="{Binding ValidationCommand}">
</KeyBinding>
</TextBox.InputBindings>
</TextBox>
Related
I am playing with SlateJS v0.34.5. Is there any way to toggle Editor readonly state?
I have figured out. So silly of me. adding readOnly property in state and then in Editor passing it as follows
<Editor readonly={this.state.readOnly} />
Then doing regular setState stuff for toggling it.
Please can anyone tell what does "{Binding .}" mean? The point refers to what? I know that we have refer to a property but I don't understand when I have to put this point
{Binding} in XAML is a markup extension, specifically, it's BindingExtension
If you look at this class, you'll see that it has a Path property. In XAML you use it like this:
{Binding Path=PathThePublicPropertyOfTheBindingContext} or, shorter by omitting Path=:
{Binding PathThePublicPropertyOfTheBindingContext}
If the object you want to bind to does not have a property you bind to, but you rather want to bind to the object itself, you use .. Say, your binding context is a string type:
public string MyObject = "Hello World";
BindingContext = MyObject;
and in XAML
<Label Text="{Binding .}">
it would display "Hello World", the content of the object itself.
My least favorite part of coding JSF 2.0 forms has to do with the handing of the id attributes of the various input elements. I am forever having trouble coding the clientID of the target component from within the backing bean, particularly since PrimeFaces tabView now includes the id of the p:tab element as part of the clientID. I waste tons of time coding, testing, then re-coding those clientIDs.
It is reminiscent of older-style assembly language programming where you have to generate tons of label names for your branches and loops. I've done of enough of that for a lifetime.
One approach I am trying is to use only auto-generated id attributes. For example one line of my form might look like this.
<h:outputLabel value="Full Name:" />
<p:inputText value="#{editUser.user.fullName}"
binding="#{editUser.compFullName}"/>
<p:message for="#{editUser.compFullName.clientId}" />
Note that I do not have an explicit id attribute. Then in the backing bean:
String clientID = getCompFullName().getClientId();
msg = new FacesMessage(FacesMessage.SEVERITY_INFO,
"Summary Message For Full Name", "Detail Message Full Name");
FacesContext.getCurrentInstance().addMessage(clientID, msg);
This always works, even if the component has a complex clientID, such as when PrimeFaces inserts the p:tab id into the clientID. (Which it does starting v 3). Rearranging the form never breaks anything.
It is, however, laborious, since I have to create UIComponent properties, getters and setters, and bind them in the form with binding attributes. Can anyone suggest a better way of doing this?
since I have to create UIComponent properties, getters and setters, and bind them in the form with binding attributes. Can anyone suggest a better way of doing this?
It's not required to bind the component to some backing bean if you don't use it in there at all. Just bind it to the view instead:
<p:inputText value="#{editUser.user.fullName}"
binding="#{compFullName}"/>
<p:message for="#{compFullName.clientId}" />
To make the code more self-documenting, I suggest to put a HashMap in the request scope by faces-config.xml:
<managed-bean>
<description>Holder of all component bindings.</description>
<managed-bean-name>components</managed-bean-name>
<managed-bean-class>java.util.HashMap</managed-bean-class>
<managed-bean-scope>request</managed-bean-scope>
</managed-bean>
with
<p:inputText value="#{editUser.user.fullName}"
binding="#{components.fullName}"/>
<p:message for="#{components.fullName.clientId}" />
Adding messages is supposed to be done by a Converter or a Validator which is trowing it as a ConverterException or ValidatorException respectively. It will automatically end up in the right message holder. Or if it are informal messages, just add it on the client ID of the UIComponent which is already available as method argument.
See also:
JSF component binding without bean property
Not that it really matters but I want to follow the best practices. When creating View Models is it considered best practice to use property getters or methods? e.g
public class ProductViewModel
{
private readonly Product _product;
public ProductViewModel(Product p)
{
_product = p;
}
public string Price
{
get { return string.Format("${0}" _product.Price.ToString("N2") };
}
}
Considering that this is a simple example is it better to use a method?
public string GetPrice()
{
return string.Format("${0}" _product.Price.ToString("N2");
}
What are the pros / cons between the two?
If you're using MVVM, then you're using databinding. Databinding binds to properties, not methods. (See the docs for the Binding.Path property -- there's not a single occurrence of the word "method" on that page. It's all about properties.)
So there's no contest. Use properties, because that's what the binding system supports.
I would lean towards a property and away from a function. The point of a view model is to present the model in a fashion suitable for displaying in a view. Usually the view and the view model talk to one another through binding, often done in XAML.
By using a method instead of a property you make wiring up the view and the view model less turn key.
Say you end up needing that price elsewhere, keeping it formatted in the old code but without the formatting in the new code. With a method you'd now need another method, or a property to get the price. With the property, you could just apply a StringFormat to the first binding.
<!-- Old code -->
<TextBlock Text="{Binding Price}" />
<!-- New code -->
<TextBlock Text="{Binding Price, StringFormat=${0:N2}}" />
<awesome:MoneyUpDown Value="{Binding Price}" />
If you are using MVVM, chances are you want INotifyPropertyChanged support, in which case properties are the way to go. There are a number of frameworks (e.g. Caliburn.Micro) that help you minimize repetitive crud code, like wiring up the notifications.
The original question was about the MVVM pattern. With plain MVC (without data binding), the answer is not as clear cut. Personally, I would still use a property over a method when getting simple data when no extra calculation or data access is required.
one caveat with the first method is that you would have to implement a second property to be able to get the price without formatting
I've got a View where I use a naming-convention on my text-fields, to indicate what should be done with the content once it is posted back to my controller.
The format is similar to:
<input type="text" name="RegistrationLine#ID" />
for updates
<input type="text" name="CreateRegistrationLine#LineNumber" /> for create
Now since I'm using this Naming-convention, regular model-binding isn't possible. But I've been reading up a bit on the subject and did find a bit of an indication that it would be possible to write a custom model binder, that should be able to help parse and bind these form elements and instantiate the objects correctly.
Please read: Bind formValue to property of different name, ASP.NET MVC
This is a bit similar to what I am doing except, I have the additional complexity of having appended information in the formelement-name that I am trying to bind to.
Am I way off base here? and if not, can any of you drop a few lines of code to show how you would start this model-binder off..
If this is a very bad approach to what I am really trying to achieve, I would love to hear suggestions for better approaches. Just note that what I want to be able to do is post back both updates and creates in one go.
I kinda have to agree with #jfar and #omar. I don't think a custom model binder is where you want to be in this instance.
You can pass a complex type to your view and simply use the full stop like #jfar mentioned.
id="Model.Person.Name.FirstName" will happily bind to an object named Person that has a class in it called Name that has a property called FirstName.
Now if you want to do some special checks on the data you could implement a partial class which would do the validations etc and populate the ModelState errors.
public partial class Name
{
public void Validate(){ }
public int CreateRegistrationLine(){ }
public bool DoSpecialActions(){ }
}
It's a little unclear what your special actions are doing so my example above may not be what you want.