Vincent Sibal's Blog : IEditableCollectionView

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.

Using IEditableCollectionView with dynamically generated GridViewColumns

vinsibal — Wed, 28 May 2008 02:29:00 GMT

I recently got a question on how to implement IEditableCollectionView with GridViewColumns that are dynamically created. Creating the columns dynamically actually doesn’t really have a big impact on IEditableCollectionView implementation. I have a sample below that dynamically adds columns but really does not differ all that much from the first sample.

Side note:

There are some design issues to think about when you want to design with an IEditableCollectionView. If you recall from the first sample I used, I relied on the template (TextBlock for non-editable, TextBox for editable) to control the user from being able to edit an item. Since a TextBox has two-way binding by default, it was actually changing the data source when in edit mode. Implementing IEditableObject and keeping a copy was my mechanism to revert changes if the user wanted to cancel the operation. There is actually another (more optimal) solution that leverages another new feature, but I’m going to have to leave that for a separate post. The new feature is actually briefly mentioned on Jossef’s post for new perf improvements in WPF 3.5 SP1 under Controls Improvements. You can probably already guess what it is, but I won’t say anything for now.

Back to the task at hand:

I want to create columns dynamically and use IEditableCollectionView. I decided to create the column templates in code and create columns for each public property of the data source. The default template is a TextBlock that binds to the particular property of the data source.

// automatically creates GridViewColumns based on the public properties

private void GenerateGridView(Type type)

{

GridView gridView = new GridView();

foreach (PropertyInfo pi in type.GetProperties(BindingFlags.Public | BindingFlags.Instance))

{

GridViewColumn column = new GridViewColumn();

// set the header

column.Header = pi.Name;

// the default cell template

FrameworkElementFactory cellTemplateFactory = new FrameworkElementFactory(typeof(TextBlock));

Binding binding = new Binding(pi.Name);

cellTemplateFactory.SetBinding(TextBlock.TextProperty, binding);

DataTemplate defaultCellTemplate = new DataTemplate();

defaultCellTemplate.VisualTree = cellTemplateFactory;

column.CellTemplate = defaultCellTemplate;

gridView.Columns.Add(column);

}

this.itemsList.View = gridView;

}

Before when I wanted to make an item editable, I changed the ListBoxItem template to a TextBox. Since I’m using columns now, there are some changes to the visual tree being used, and I cannot just change the whole ListBoxItem to a TextBox. Oh, and now that I’m using ListView, they are ListViewItems now and not ListBoxItems.

When using a GridView as the View, the ListViewItem uses a GridViewRowPresenter which will contain ContentPresenters for each column. Now each time I have to update the item’s template, I’m going to drill down into the ListViewItem and update the cell template of each ContentPresenter to be a TextBox.

private void UpdateContentTemplate(bool isEditing, ListViewItem lvi)

{

// get the content presenter of the particular column
GridViewRowPresenter rowPresenter = this.GetVisualChild<GridViewRowPresenter>(lvi);

// go through each column and update the content template

int columnIndex = 0;

foreach (GridViewColumn column in rowPresenter.Columns)

{

// get the content presenter of the particular column
ContentPresenter cp = this.GetVisualChild<ContentPresenter>(rowPresenter, columnIndex);

DataTemplate cellTemplate = new DataTemplate();

FrameworkElementFactory cellTemplateFactory;

// if editing, set the template to a textbox, else to a textblock

if (isEditing)

{
cellTemplateFactory = new FrameworkElementFactory(typeof(TextBox));

Binding binding = new Binding(column.Header.ToString());

binding.UpdateSourceTrigger = UpdateSourceTrigger.PropertyChanged;

cellTemplateFactory.SetBinding(TextBox.TextProperty, binding);
}

else

{
cellTemplateFactory = new FrameworkElementFactory(typeof(TextBlock));

Binding binding = new Binding(column.Header.ToString());

cellTemplateFactory.SetBinding(TextBlock.TextProperty, binding);
}

cellTemplate.VisualTree = cellTemplateFactory;

cp.ContentTemplate = cellTemplate;

columnIndex++;
}
}

The rest of the code is basically the same as in the first sample (with some refactoring). Adding/Removing/Editing all work the same and there are no changes to the data source. For kicks I added commands in addition to the buttons since I was getting tired of having to mouse down to the buttons each time I wanted to edit and submit. The commands are, F2 = Edit, Enter = Submit, Esc = Cancel. Note that this isn’t the most efficient but hopefully it will give you some ideas to expand on. Here is the project.

WPF 3.5 SP1 feature: IEditableCollectionView

vinsibal — Wed, 21 May 2008 00:00:00 GMT

Motivation

A CollectionView is your interface into manipulating a collection of data items in an ItemsControl. Common tasks with this view often involve applying sorting, filtering, and grouping. In lieu of supporting a DataGrid control, transactional adding/editing/removing is an essential feature for data manipulation and a new view has been added in WPF 3.5 SP1 to support this functionality.

What is it?

IEditableCollectionView is a new collection view that you can use to supports adding and removing new items, as well as editing items in a transactional way. It is implemented by ListCollectionView (the default view for ObservableCollection) and BindingListCollectionView (the default view for DataTable). I will go through an example to further describe it and summarize afterwards.

Background on the example

I will be creating a ListBox with some data that you can add/remove/edit each item. You also have the option to cancel in the middle of editing the item. I will use buttons to trigger an item for editing, adding, removing, etc. Here is the ListBox xaml:

</Style>

<ListBox Name="itemsList"

ItemsSource="{StaticResource products}"

ItemContainerStyle="{StaticResource listBoxDefaultStyle}"/>

When the ListBox is not in edit mode it will use a template of TextBlocks.

</StackPanel>

</DataTemplate>

When it is in edit mode, it will use a template of TextBoxes (I will set the DataTemplate dynamically in code).

</StackPanel>

</DataTemplate>

How do I use it?

Just like the other collection views, you can obtain a reference to this collection using the CollectionViewSource.GetDefaultView,

// retrieve a reference to the view

ICollectionView view = CollectionViewSource.GetDefaultView(itemsList.Items);

IEditableCollectionView iecv = (IEditableCollectionView)view;

Before I go any further, there is an important point to note about delegation of work. When the data source implements IEditableObject, the IEditableCollectionView will call BeginEdit() when a new item is added or an existing item is opened for edit. It will call CancelEdit() when the item is cancelled and EndEdit() when the item is committed. IEditableCollectionView lets the app author handle this part of the transaction.

In my data source, I will be creating a copy of the selected data item when it is opened for edit. If the procedure is cancelled, I will use the copy to reset the original state, otherwise the new data will update the data source. I’ve only included the relevant information of the data source here.

public class Product : INotifyPropertyChanged, IEditableObject

{

private Product copy;

#region IEditableObject Members

public void BeginEdit()

{

if (this.copy == null)

this.copy = new Product();

copy.Book = this.Book;

copy.Author = this.Author;

copy.Price = this.Price;

}

public void CancelEdit()

{
this.Book = copy.Book;

this.Author = copy.Author;

this.Price = copy.Price;
}

public void EndEdit()

{
copy.book = null;

copy.author = null;

copy.price = 0;
}

#endregion IEditableObject Members

}

Let’s first focus on editing items. To initiate an item to be edited you call IEditableCollectionView.EditItem(). As I just discussed, this will call BeginEdit on my selected data item. Here is the code that is called when the edit button is clicked (Notice the template of the item container is updated here):

private void edit_Click(object sender, RoutedEventArgs e)

{

// edit the item

iecv.EditItem(itemsList.SelectedItem);

// update the template

ListBoxItem lbItem = (ListBoxItem)itemsList.ItemContainerGenerator.ContainerFromItem(iecv.Current EditItem);

lbItem.ContentTemplate = (DataTemplate)this.myGrid.FindResource("EditingTemplate");

}

So now that the current selected item is editable, the changes to it can either be submitted or cancelled. We shall look at the submitted scenario next. To commit changes, you call IEditableCollectionView.CommmitEdit(). This will then call EndEdit() on my data item where I reset my copy of the data as it is not needed anymore. Here is the code when the submit button is clicked:

private void submit_Click(object sender, RoutedEventArgs e)

{

// update the template

ListBoxItem lbItem = (ListBoxItem)itemsList.ItemContainerGenerator.ContainerFromItem(iecv.Current EditItem);

iecv.CommitEdit();

lbItem.ContentTemplate = (DataTemplate)this.myGrid.FindResource("DefaultTemplate");

}

The cancel scenario is very similar to the submit code, but instead CancelEdit() is called on my data item where I reset it’s values to the copy that I stored from BeginEdit():

private void cancel_Click(object sender, RoutedEventArgs e)

{

// update the template

ListBoxItem lbItem = (ListBoxItem)itemsList.ItemContainerGenerator.ContainerFromItem(iecv.Current EditItem);

iecv.CancelEdit();

lbItem.ContentTemplate = (DataTemplate)this.myGrid.FindResource("DefaultTemplate");

}

Adding new items and removing items follow a similar pattern where the view will call BeginEdit, CancelEdit, and/or EndEdit on the data item. One important difference however is how it is managed for you. While I was managed part of the editing transaction, the IEditableCollectionView will managed the addition and removal of an item. When IEditableCollectionView.AddNew() is called, a new data item is actually added to the data source by the collection view. In BeginEdit, you have the option to initialize the new item to default data. Same goes when CancelNew() or Remove() is called. The item that was added or selected is actually removed from the data source by the collection view. There is no additional code that you need to write to create the new data item and manually add it to the data source. You can check out the full project attached to view the source for adding and removing as well as the editing that I talk about above. It works with the WPF 3.5 SP1 bits.

For completeness, here is the full list of APIs from IEditableCollection. I try to make use of most of them in my project.

public interface IEditableCollectionView

{

bool CanAddNew { get; }

bool CanCancelEdit { get; }

bool CanRemove { get; }

object CurrentAddItem { get; }

object CurrentEditItem { get; }

bool IsAddingNew { get; }

bool IsEditingItem { get; }

NewItemPlaceholderPosition NewItemPlaceholderPosition { get; set; }

object AddNew();

void CancelEdit();

void CancelNew();

void CommitEdit();

void CommitNew();

void EditItem(object item);

void Remove(object item);

void RemoveAt(int index);

}