4

Say I am trying to implement a piece of functionality in which a text box only allows integers to be inputted in by the user. I can implement this two ways, using a ValidationRule that checks whatever the user inputs and binding it to the text property through the XAML or I can create a new behavior and attach it to the control (not through binding).

Examples of the XAML on both:

Behavior: <TextBox behaviors:DigitsOnlyBehavior.IsDigitOnly="True"/>

ValidationRule which binds to the Window's Text property

<TextBox>
    <TextBox.Text>
        <Binding RelativeSource = "{RelativeSource Mode=FindAncestor, AncestorType=Window}" Path="Text" UpdateSourceTrigger="PropertyChanged" Mode="TwoWay">
            <Binding.ValidationRules>
                <utils:RestrictInputTypeValidator Restriction="IntegersOnly" ValidatesOnTargetUpdated="True"/>
            </Binding.ValidationRules>
        </Binding>
    </TextBox.Text>
</TextBox>

What are the advantages and disadvantages of these approaches? When should I use them? Or is it a matter of preference?

Anatoliy Nikolaev
  • 22,370
  • 15
  • 69
  • 68
Alexander Ventura
  • 1,150
  • 1
  • 10
  • 32

1 Answers1

0

With Behaviors I like and expect a "positive" scenario/workflow without errors. The focus is no errors. The user gets pretty quickly that when they type an 'a' in the TextBox with Numeric behavior that it doesn't take it, that it's a numeric textbox, and this is how it works.

With Validation, the focus seems to be more on the error. I can have a Numeric TextBox, but I also don't take numbers beyond 100, if you type '101', I let you know that this is not acceptable. The focus here is to guide user into what is unacceptable by throwing a validation error.

Behavior Advantages:

  • Prevention (you don't let the user shoot themselves in the foot) by entering bad data.
  • Model stays clean. TextBox's Binding doesn't even hit the setter, as the behavior prevents it, hence, no XAML triggered back with PropertChanges, or ValidationErrors, etc.

Behavior Disadvantage:

-could be confusing , so if you put the logic not to accept '101', there is no default way to guide the user.

denis morozov
  • 6,236
  • 3
  • 30
  • 45
  • I am not really sure about both behavior advantage listed. As far as I know, using validation rule you can also prevent entering bad data AND keep model clean by "not hitting the setter". I have used validation rule several times and it has all the features I need. – guilhermecgs Jul 18 '13 at 17:36
  • The only drawback I see using validation rule is: How do you know in ViewModel if all fields are valid? You can solve it by using Validation.Error="OnFieldValidationError" (but it is a custom solution) – guilhermecgs Jul 18 '13 at 17:41
  • If the validation fails, the property is not updated. So even with ValidationRules, the model remain clean. – Alexander Ventura Jul 18 '13 at 18:36
  • well, except for the Validation Error that will be populated, and if you query/trigger on it, then the model isn't clean... – denis morozov Jul 18 '13 at 19:40