Inside MainViewModel.OnEditSelectedItem() the model item to be edited is cloned, and passed to EditModel(). The parameter is Dynamic type rather than smModelBase, to force the generic methods to use the actual type of the item passed. EditModel() can take any object that descends from smModelBase. In the StaffManager application, editing functionality is handled in a completely generic manner by the injected IStaffManagerNavigationService instance. I prefer the alternative approach – only one item can be edited at a time, and it’s very obvious what save and cancel relate to. After some of these have been closed and perhaps just the first level edit dialog remains, the user is still faced with a window with save & cancel buttons on it – and it’s totally ambiguous just how much (if any) will be undone if they click cancel. I’ve seen applications where multiple levels of edit screens can be opened one after another – children of children being created or updated. So far as editing is concerned, I like to have my applications operate in as clear a manner is possible. This messenger acts like a decoupled event handler – messages of a specific type can be globally broadcast within an application, and will be acted upon by all registered receivers of that type. As with perIoC, this is just a facade over the chosen implementation (in this case another utility from MVVMLight – the Messenger class), providing a single point of reference. Note the way that the SelectedItem can be set indirectly from any presenter / ViewModel, using the perMessengerService. This is used for the non-editing mode of each presenter. perControlHost has been updated – allowing an option to display a text string rather than the hosted control. The presenter classes that make up these templates will also be used for the editing screen, providing a consistent layout throughout the application. As with the TreeView, there are a set of data templates to control the display. The other half of the screen holds a ContentControl, the DataContext of which is bound to the selected item from the TreeView – a wrapper ViewModel instance. I’ll cover an alternative way to handle images for disabled buttons in a future post. Alexey Potapov’s Greyable Image class provides the ImageGreyer.IsGreyable attached property, which will create an alternative image based on the colours of the original bitmap, to indicate a disabled state. The two buttons will cycle through the set of matches. There is also a person search function – as you type into the text box, the application will search through the full list of people models (not all corresponding people view models are guaranteed to have been created). The TreeView display is built up using a different data template for each ViewModel type. The left hand half of the main screen holds the full collection of item data, loaded from the data service as required using the Lazy Loading methodology. As the data structure is hierarchical (people within departments), it makes sense to reflect that in the user interface – using a TreeView rather than a linear list in a data grid. I’ve changed the layout of the StaffManager demo application substantially from the previous versions. Having introduced a number of different MVVM / WPF concepts over this blog series, it’s time to bring everything together into one coherent and cleanly structured application. Great things are done by a series of small things brought together.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |