Vincent Sibal's Blog : BindingGroups

WPF BindingGroup and Validation Feedback

vinsibal — Mon, 08 Sep 2008 15:50:00 GMT

Recap

In a previous set of posts I covered the introduction to the BindingGroup feature and I expanded in a following post with an example of using BindingGroup and IEditableCollectionView together. Last thing on the BindingGroup list to discuss is the additional validation feedback options with item-level validation.

Motivation

For item-level validation, the target element is often a container of some kind, such as a ListViewItem, Panel, or form. Some common scenarios for showing item-level validation feedback are possibly a ListViewItem wanting to show an exclamation mark in a particular column or a panel wanting to display error information in a dedicated child element.

Validation Feedback

Two new APIs have been added to the Validation class to enable feedback for BindingGroups. The APIs include Validation.ValidationAdornerSite and Validation.ValidationAdornerSiteFor. These attached properties work together to point to the element that will show the validation error. The remarks in MSDN describe both attached properties quite well actually so I’m not going to describe them again here. What I will do is go through some different usage scenarios.

In the BindingGroups and IEditableCollectionView post, I used standard validation that existed before SP1. I placed it on the entire row item. That is one option that you have to display validation feedback. I list it here for reference.

<Setter.Value>

<TextBlock DockPanel.Dock="Right" Foreground="Red"

FontSize="14" FontWeight="Bold">*</TextBlock>

</Border>

</DockPanel>

</ControlTemplate>

</Setter.Value>

</Setter>

<Style.Triggers>

<Setter Property="ToolTip"

Value="{Binding RelativeSource={RelativeSource Self},

Path=(Validation.Errors)[0].ErrorContent,

Converter={StaticResource ItemErrorConverter}}"/>

</Trigger>

</Style.Triggers>

</Style>

Another way that you may want to display validation errors is through a dedicated area in your UI. Let’s say that you have a TextBlock or ListBox specifically for validation errors. You can design it in a couple ways using the new Validation APIs. One way, you can set Validation.ValidationAdornerSiteFor on an error ListBox to point to the element that is being validated (which in this case is the ListViewItem). Here is an example:

<StackPanel.DataContext>

</MultiBinding>

</StackPanel.DataContext>

<ListBox MinHeight="30"

Validation.ValidationAdornerSiteFor="{Binding}"

ItemsSource="{Binding Path=(Validation.Errors)}">

<ListBox.ItemTemplate>

</DataTemplate>

</ListBox.ItemTemplate>

</ListBox>

</StackPanel>

I had to use a MultiBinding to get the current ListViewItem visual to set as the DataContext for the error ListBox. As you can see, there is a bit of work involved taking this route. The next approach I am going to discuss uses less code and may be a better approach for lists. But there are other scenarios where this particular approach is more convenient. The reason it is a bit involved in the first place is because you are dealing with a list of items and you need to find the correct item. If you were dealing with a form instead of a ListView all you have to do is set the ValidationAdornerSiteFor on the form element instead of having to find it in a converter. That is just something to keep in mind.

The second approach that you can do is set the Validation.ValidationAdornerSite on the ListViewItem to point to the error ListBox. Here is an initial implementation:

<!—WARNING: Setting ValidationAdornerSite this way may have an undesired side effect-->

<Setter Property="Validation.ValidationAdornerSite"

Value="{Binding ElementName=lb_ErrorList}" />

</Style>

<ListBox Name="lb_ErrorList" MinHeight="30"

ItemsSource="{Binding RelativeSource={RelativeSource Self},

Path=(Validation.ValidationAdornerSiteFor).(Validation.Errors)}">

<ListBox.ItemTemplate>

</DataTemplate>

</ListBox.ItemTemplate>

</ListBox>

</StackPanel>

By setting Validation.ValidationAdornerSite on the ListViewItem, lb_ErrorList now has access to the ListViewItem through Validation.ValidationAdornerSiteFor on itself. There is one problem with the above code however. Validation.ValidationAdornerSite is a static property and therefore will only exist as a single entity. When each ListViewItem attaches to Validation.ValidationAdornerSite, the value of Validation.ValidationAdornerSite will end up being the last ListViewItem that attached to it. What this means is that anytime there is a validation error, lb_ErrorList will check the last ListViewItem for Validation.Errors (instead of the current ListViewItem that is being edited). To correct this, you can update Validation.ValidationAdornerSite dynamically. A possible implementation for this is to remove the Style set on the ListViewItem and attach to the Validation.Error event. In this event, you can set Validation.ValidationAdornerSite like so:

private void itemsList_Error(object sender, ValidationErrorEventArgs e)

{

Validation.SetValidationAdornerSite((DependencyObject)e.OriginalSource, this.lb_ErrorList);

}

Now when a validation error occurs, lb_ErrorList will check the correct ListViewItem for validation errors. I have the full code for this solution attached.

One last scenario that I want to cover is showing feedback on a particular property within an item. Let’s say as the item-level validation occurs a failure occurs between two properties and you want to show an error on the specific property. The approach for this one is very similar to the second approach I discussed. In my example I use the column header to show any validation error feedback and it is in the Validation.Error event where I set the ValidationAdornerSite to the correct column header. Here is a snippet of the template for the GridViewColumnHeader and the full code you can see from the solution attached.

<Setter.Value>

<TextBlock.Visibility>

</MultiBinding>

</TextBlock.Visibility>

</TextBlock>

</StackPanel>

</ControlTemplate>

</Setter.Value>

</Setter>

<Setter Property="ToolTip"

Value="{Binding RelativeSource={RelativeSource Self}, Path=(Validation.ValidationAdornerSiteFor).(Validation.Errors)[0].ErrorContent}" />

</Style>

Download the complete solution here.

BindingGroups and IEditableCollectionView

vinsibal — Fri, 22 Aug 2008 19:06:00 GMT

Recap

In a previous post I introduced the BindingGroups. Well now I want to get into some of the things you may run into when trying to use IEditableCollectionView with BindingGroup.

BindingGroups and IEditableCollectionView

So now with the BindingGroup feature in WPF 3.5 SP1, there is this slight duplication of transaction methods between the two types, BindingGroup and IEditableCollectionView. The duplication occurs with the two types both having BeginEdit, CancelEdit, and CommitEdit. So what do I use? Well let’s take a refresher on what both of the types offer.

IEditableCollectionView provides editing capabilities to a collection. BindingGroup contains a collection of bindings and ValidationRule objects that are used to validate an object. What they both provide are the transactional editing capabilities by supporting the IEditableObject pattern. What IEditableCollectionView provides over BindingGroup are adding new items to the collection, deleting items from the collection, and keeping currency on the item being edited or added. What BindingGroup offers over IEditableCollectionView is its item-level validation. Both have very attractive attributes and it is most likely that you will need a combination of both. Here are some things to take into account when using both (I’m going to use the sample from my post on IEditableCollectionView as a starting point to build on):

Currency with IEditableCollectionView

If currency during editing is important to you, such as IECV.IsAddingNew, IECV.CurrentAddItem, IECV.IsEditingItem, and IECV.CurrentEditItem, then you have to call the IECV.BeginEdit, IECV.CancelEdit, and IECV.CommitEdit for those currency values to be updated correctly. For example, you cannot call IECV.BeginEdit then BindingGroup.CommitEdit in place of IECV.CommitEdit and expect currency on the IECV to be correct after the commit.

Editing Existing items

To begin editing an existing item in the collection, you call IECV.EditItem. Calling BindingGroup.BeginEdit is unnecessary if IECV.EditItem is called as it only calls IEditableObject.BeginEdit on each item which is already accomplished by IECV.EdtiItem. Also, there is no state kept when calling BindingGroup.BeginEdit. Here is a possible implementation which is basically the same as before:

public void EditItem()

{

if (itemsList.SelectedItem == null)

{
MessageBox.Show("No item is selected.");

return;
}

if (iecv.IsEditingItem || iecv.IsAddingNew)

{

MessageBox.Show("Please finish editing or adding item before editing or adding new item.");

return;

}

// edit the item

iecv.EditItem(itemsList.SelectedItem);

// get the listviewitem

itemsList.ScrollIntoView(itemsList.SelectedItem);

ListViewItem lbItem = (ListViewItem)itemsList.ItemContainerGenerator.ContainerFromItem(itemsList.SelectedItem);

// then update the template to an editing state

Helpers.UpdateContentTemplate(/* isEditing */true, lbItem);

}

To commit an edit of an existing item you have several choices and it also depends on how you want to treat validation failures. Let’s say that if a failure occurs, the item is not committed and no other items can be edited until the failure is fixed or edit is cancelled. Here is one possible implementation:

public void SubmitItem()

{

if (!iecv.IsEditingItem && !iecv.IsAddingNew)

{
MessageBox.Show("No item is editable for submission.");

return;
}

ListViewItem lbItem = null;

if (iecv.IsEditingItem)

{

// get the listviewitem
itemsList.ScrollIntoView(iecv.CurrentEditItem);

lbItem = (ListViewItem)itemsList.ItemContainerGenerator.ContainerFromItem(iecv.CurrentEditItem);

if (lbItem.BindingGroup.CommitEdit())

{
// iecv will do any necessary cleanup on commit

iecv.CommitEdit();

// update the template to non-editing state

      Helpers.UpdateContentTemplate(/* isEditing */false, lbItem);
    }
    }

}

When calling BindingGroup.CommitEdit I am letting all the validation rules run (include all the different ValidationSteps) and committing the data to the source. If that succeeds I’m still calling IECV.CommitEdit because I want to keep currency udpated. Notice that I’m using iecv.CurrentEditItem to retrieve the ListViewItem so it’s important that currency is correct. There is also clean up that it does relating to grouping. One side effect is that IEditableObject.EndEdit will be called twice. If that is undesirable you can replace BindingGroup.CommitEdit with BindingGroup.UpdateSources which will not call IEditableObject.EndEdit. The only issue is that you won’t be able to run validation on rules marked as ValidationStep.CommittedValue.

Another thing to notice is how the bindings are updated. If I was not using BindingGroup, I would have to do my own updates to the sources. In my IEditableCollectionView post I was doing that by setting UpdateSourceTrigger to PropertyChanged. Now with BindingGroup that is unnecessary as it will take care of that for you with CommitEdit or UpdateSources. But be careful as ValidateWithoutUpdate is a not the same. Say I changed the code in SubmitItem to be like this:

public void SubmitItem()

{

if (!iecv.IsEditingItem && !iecv.IsAddingNew)

{
MessageBox.Show("No item is editable for submission.");

return;
}

ListViewItem lbItem = null;

if (iecv.IsEditingItem)

{

// get the listviewitem
itemsList.ScrollIntoView(iecv.CurrentEditItem);

lbItem = (ListViewItem)itemsList.ItemContainerGenerator.ContainerFromItem(iecv.CurrentEditItem);

//NOTE: will NOT update the source unless source is

// updated manually like setting UpdateSourceTrigger

// to PropertyChanged

if (lbItem.BindingGroup.ValidateWithoutUpdate())

{
// iecv will do any necessary cleanup on commit

iecv.CommitEdit();

// update the template to non-editing state

      Helpers.UpdateContentTemplate(/* isEditing */false, lbItem);
    }
    }

}

If a validation failure occurs all is good as the logic is the same, but if validation is successful my source does not actually update. That is because I am relying on BindingGroup to update the source but I’m not updating anything from calling ValidateWithoutUpdate. I know that seems obvious but it can be a little confusing if you assume iecv.CommitEdit will update the sources.

Cancelling an edit also requires both IECV.CancelEdit and BindingGroup.CanceEdit. The former is necessary to keep currency updated and the latter so the target bindings are updated so revalidation can execute correctly. Here is a possible implementation:

public void CancelItem()

{

if (!iecv.IsEditingItem && !iecv.IsAddingNew)

{
MessageBox.Show("No item is editable to cancel.");

return;
}

ListViewItem lbItem = null;

if (iecv.IsEditingItem)

{

// get the listviewitem
itemsList.ScrollIntoView(iecv.CurrentEditItem);

lbItem = (ListViewItem)itemsList.ItemContainerGenerator.ContainerFromItem(iecv.CurrentEditItem);

// Need to call BindingGroup.CancelEdit in order for revalidate

// to occur correctly on the item

lbItem.BindingGroup.CancelEdit();

// Revalidates so ValidationErrorTemplate is cleared

lbItem.BindingGroup.ValidateWithoutUpdate();

iecv.CancelEdit();

}

// update the template to non-editing state

Helpers.UpdateContentTemplate(false, lbItem);

}

Editing New Items

Adding a new item to the collection hasn’t changed and you still just call IECV.AddNew. Cancelling a new item hasn’t change either. You call IECV.CancelNew and there are no BindingGroup methods involved. What does need to update a bit but is pretty much the same as what I’ve already described above is when you are committing a new item. Here is the updated code:

public void SubmitItem()

{

if (!iecv.IsEditingItem && !iecv.IsAddingNew)

{
MessageBox.Show("No item is editable for submission.");

return;
}

ListViewItem lbItem = null;

if (iecv.IsEditingItem)

{

…

}

else if (iecv.IsAddingNew)

{

// get the listviewitem
itemsList.ScrollIntoView(iecv.CurrentAddItem);

lbItem = (ListViewItem)itemsList.ItemContainerGenerator.ContainerFromItem(iecv.CurrentAddItem);

if (lbItem.BindingGroup.CommitEdit())

{
// iecv will do any necessary cleanup on commit

iecv.CommitNew();

// update the template to non-editing state

      Helpers.UpdateContentTemplate(/* isEditing */false, lbItem);
    }
    }

}

The only thing you want to be careful about here is currency when using a BindingListCollectionView (DataTable for example). Note that this issue does not occur with a ListCollectionView. When BindingGroup.CommitEdit is called it will call IEditableObject.EndEdit for each item as expected. However, the IEditableObjectEndEdit implementation in DataRowView will actually trigger BindingListCollectionView to update its currency. So iecv.CommitNew doesn’t actually do anything for the BindingListCollectionView case but it is a good idea to keep it there as it is needed for the other IEditableCollectionView cases (well currently just one other case, ListCollectionView).

Putting it all together

I’ve taken what I discussed above and put it in a sample here. I have one version with a ListCollectionView and one with a BindingListCollectionView so you can experiment with both. I also have a version with just IEditableCollectionView. For the BindingListCollectionView sample you will need to install the Northwind DB. Instructions are included in the sample.

As an alternate implementation, if currency wasn’t that important to me or if I were to keep track of state on my own, I could have implemented it such that I use IECV for adding and removing items and BindingGroup for transactional editing. That would eliminate the redundant calls to both IECV and BindingGroup which eliminates the multiple calls to IEditableObject.EndEdit and IEditableObject.CancelEdit. I’ll leave this implementation as an exercise for the interested reader.

Coming next…

Next I will be talking a little on the usage of validation feedback through Validation.ValidationAdornerSiteFor. Read about it here.

WPF 3.5 SP1 Feature: BindingGroups with Item-level Validation

vinsibal — Tue, 12 Aug 2008 07:14:00 GMT

Motivation

Before 3.5 SP1, the binding validation system worked with only one binding at a time. What made this difficult in some scenarios was when validation was required on a set of bound objects. Some typical examples that come to mind are a form of data items that are submitted all at once or a ListView or DataGrid row that is committed all at once. You can put a validation rule on each bound object and validate their values individually but there was no readily available way in the binding validation system to validate multiple objects together. Now in 3.5 SP1 a solution has been created for this, Binding Groups.

What is it?

A BindingGroup encapsulates and has access to a set of related bindings. These related bindings are bindings that share the same data context as the BindingGroup and/or bindings that have explicitly declared membership to the BindingGroup. With this set of bindings, the BindingGroup can now provide services such as validation of all the encapsulated bindings together and transactional editing.

How do I define a BindingGroup?

We will use an example to illustrate how to define a BindingGroup. Let’s say this is the data context that I will use (I just went canoeing recently which influence my choice of data):

public class BoatRentalCustomer

{

public string FirstName { get; set; }

public string LastName { get; set; }

public DateTime? DateOfBirth { get; set; }

public int BoatCheckOutID { get; set; }

public DateTime? StartDate { get; set; }

public DateTime? EndDate { get; set; }

}

With this data I want to use it in a form to be filled in by the customer. Here is the xaml (I only put the relevant information for this example):

<Grid>

<Button Click="submit_Click">Submit</Button>

</StackPanel>

</Grid>

As I said in the Motivation section, we can add validation to each binding and validate them individually, but there wasn’t a built in mechanism to validate them as a group. To do that, we can add a BindingGroup to the Grid:

<Grid>

<Grid.BindingGroup>

<BindingGroup.ValidationRules>

...

</BindingGroup.ValidationRules>

</BindingGroup>

</Grid.BindingGroup>

<Button Click="submit_Click">Submit</Button>

</StackPanel>

</Grid>

Assuming that I’ve set the Grid.DataContext to be an instance of BoatRentalCustomer, the BindingGroup I set on the Grid will have access to all the bindings I set within the Grid. This example shows how the BindingGroup gets bindings from the same DataContext but it is also possible to get bindings through explicit membership declaration like this slightly modified example below:

<Grid>

<Grid.BindingGroup>

<BindingGroup.ValidationRules>

...

</BindingGroup.ValidationRules>

</BindingGroup>

</Grid.BindingGroup>

<TextBox Text="{Binding Path=FirstName}"

FontSize="{Binding ElementName=sliderFontSize,

Path=Value,

BindingGroupName=FormBindingGroup}" />

<Button Click="submit_Click">Submit</Button>

</StackPanel>

</Grid>

I named the BindingGroup, “FormBindingGroup”, and added a binding to the FontSize property on one of the TextBox elements. Notice that in the binding I explicitly declare BindingGroupName to be set to “FormBindingGroup”. By doing this, the BindingGroup will have access to the bindings under the same DataContext as well as the bindings associated with it by the same BindingGroupName. The ability to declare explicit membership to a BindingGroup are for scenarios where bindings don’t use DataContext (explicit Source or ElementName like in the example above) and/or bindings that use a different DataContext that want to participate in the same group validation.

From the previous example you saw that Grid had a property named BindingGroup. You may be wondering where BindingGroup is actually defined. BindingGroup has been added to FrameworkElement and FrameworkContentElement so it can be associated with a set of bindings on a per element basis.

public class Framework[Content]Element

{

public static readonly DependencyProperty BindingGroupProperty;

public BindingGroup BindingGroup { get; set; }

}

It has also been added to ItemsControl so it can be associated with a set of bindings per each generated container. The pattern is similar to ItemTemplate.

public class ItemsControl

{

public static readonly DependencyProperty ItemBindingGroupProperty;

public BindingGroup ItemBindingGroup { get; set; }

}

And as you saw the use of BindingGroupName, that property has been defined in BindingBase.

public class BindingBase

{

public string BindingGroupName { get; set; }

}

How do I use it? (Part 1)

So now I know where to define a BindingGroup and how bindings get associated with it, but how do I use it? Let’s first look at the BindingGroup class and then dig into the common APIs and common scenarios. Here is the BindingGroup class:

public class BindingGroup : DependencyObject

{

public Collection<BindingExpressionBase> BindingExpressions { get; }

public bool CanRestoreValues { get; }

public IList Items { get; }

public string Name { get; set; }

public bool NotifyOnValidationError { get; set; }

public Collection<ValidationRule> ValidationRules { get; }

public void BeginEdit();

public void CancelEdit();

public bool CommitEdit();

public object GetValue(object item, string propertyName);

public bool TryGetValue(object item, string propertyName, out object value);

public bool UpdateSources();

public bool ValidateWithoutUpdate();

}

You have access to the associated bindings through the BindingExpressions property and can set group validation rules through the ValidationRules property. You may have notice all these transactional methods in this class such as BeginEdit, CancelEdit, etc. Well, as part of group validation you have the ability to control whether the new data to that item is committed as a whole and/or reverted back to its previous state. The two major areas of BindingGroup that I want to get into are its validation rules and how its methods are used to update the binding sources. First, let’s discuss validation.

The ValidationRule class has been updated with a couple APIs to work with BindingGroup. Here are the new APIs:

public abstract class ValidationRule

{

public bool ValidatesOnTargetUpdated { get; set; }

public ValidationStep ValidationStep { get; set; }

}

public enum ValidationStep

{

RawProposedValue = 0,

ConvertedProposedValue = 1,

UpdatedValue = 2,

CommittedValue = 3,

}

The ValidationStep property is used to let ValidationRule know when to apply the validation. RawProposedValue means the rule is applied to the unconverted value. This is the default step which also was the current behavior for ValidationRule prior to this feature. ConvertedProposedValue means the rule is applied to the converted value, UpdatedValue means the rule is applied after writing to the source, and CommittedValue means the rule is applied after committing changes. ValidatesOnTargetUpdated is used to trigger validation when the source is updating the target.

So now we have an idea of how validation rule may be used but how does this relate to the transactional methods of BindingGroup? Note that to use a BindingGroup for transactional editing, you should define IEditableObject on your data item.

BeginEdit, CancelEdit, and CommitEdit work similar to IEditableCollectionView’s versions where they will call IEditableObject.BeginEdit, IEditableObject.CancelEdit, and IEditableObject.EndEdit respectively on the data item. In addition to CommitEdit, you also have UpdateSources and ValidateWithoutUpdate. These three methods (CommitEdit, UpdateSources, and ValidateWithoutUpdate) are the main methods that you will call to validate and update your source. That brings up a point on how bindings update in a BindingGroup. UpdateSourceTrigger for bindings that belong to the BindingGroup are set to Explicit by default. That means you will need to use the BindingGroup APIs to update the bindings (CommitEdit or UpdateSources). Validation and updating methods work like this:

· ValidateWithoutUpdate: runs all validation rules marked as RawProposedValue or ConvertedProposedValue.

· UpdateSources: does the same as ValidateWithoutUpdate, and then if no errors were found, it writes all the values to the data item and runs the validation rules marked as UpdateValue.

· CommitEdit: does the same as UpdateSources, and then runs the rules marked as CommittedValue.

How do I use it? (Part 2)

Ok, we made it this far. So I know where to define my BindingGroup, how to setup when I want my validation rules ran and how to update my bindings. Let’s look at what kinds of things I can do to actually validate the item inside the ValidationRule.Validate method.

The value input parameter to Validate is the actual BindingGroup. With the BindingGroup you can query for the data on the item. The important BindingGroup APIs for the actual validation include Items, GetValue, and TryGetValue. The Items collection contains the unique data items used by the bindings in the group. GetValue looks for the binding that uses the given item and propertyName parameter values and returns the value appropriate to the current validation step. So for example, if the validation step is RawProposedValue or ConvertedProposedValue, the data source has not been updated yet when the Validate method is called, but by querying for the value using GetValue you can get what the value will be (as long as it passes validation). Here is an example Validate method:

public override ValidationResult Validate(object value, CultureInfo cultureInfo)

{

BindingGroup bindingGroup = (BindingGroup)value;

BoatRentalCustomer customer = (BoatRentalCustomer)bindingGroup.Items[0];

object startDateObj = bindingGroup.GetValue(customer, "StartDate");

DateTime? startDate = DateTime.Parse((string)startDateObj);

object endDateObj = bindingGroup.GetValue(customer, "EndDate");

DateTime? endDate = DateTime.Parse((string)endDateObj);

// check start and end date together

if (startDate.Value > endDate.Value)

{

return new ValidationResult(false, string.Format(

"StartDate: {0}, cannot be greater than EndDate: {1}",

startDate,

endDate));

}

else

{
return new ValidationResult(true, null);
}

}

You’ll notice that I am assuming the data item is Items[0]. If the BindingGroup has bindings from more than one data source then you will have to handle that as the Items collection will be greater than one. I’ve also been pretty optimistic about getting the proposed values as well as parsing the DateTime. This example is for demonstration purposes only but in a production level application you will probably want to use TryGetValue and TryParse. So inside the Validate method I have access to the entire item and in the example I validate the start and end date together.

Where we are…

Hopefully I still have your attention after all that. I know it’s a lot to go through. Just to summarize a bit, a BindingGroup enabled you to validate data at the item-level as opposed to the property-level. This is possible because the BindingGroup has access to all the bindings associated with the data item (assuming you set the BindingGroup that way). BindingGroup is available on all FrameworkElements, FrameworkContentElements, and ItemsControls. You set the validation rules on the actual BindingGroup and in the ValidationRule.Validate method you are given the BindingGroup where you can query for all the properties on the item being validated. I’ve attached a small sample to demonstrate some of the concepts discussed here.

So what’s left? Well, there are two more important topics that should be discussed. One is the new additions to validation feedback and the other is how BindingGroup works in conjunction with IEditableCollectionView. I will save both these topics for another post as there is enough here to digest. This does cover about 95% of the new APIs relating to BindingGroup so there isn’t too much more to cover. = )

However, BindingGroup and IEditableCollectionView can be a bit confusing on when and how to use them so I do want to talk more on that. Read more on BindingGroup and IEditableCollectionView here. And you can read on BindingGroup and ValidationFeedback here.