|
ichill,
If you look at the implementation of StaffingResourceNameEditorViewModel, which is the ViewModel that lets you edit the name, you'll notice that it doesn't set the properties on the entity directly and that the corresponding view is not bound to the entity's properties.
The entity's properties are set once you Ok out of the popup in StaffingResourceSummaryViewModel (see below). At that point the property interceptor is invoked and the strings are trimmed. If StaffingResourceNameEditorViewModel would set the properties directly, we would have to roll back the entity if the user clicks Cancel and risk losing other pending changes or we would have to reset just the properties with the original values. By not changing the actual properties until the user hits Ok, we don't have to do anything if they click Cancel and the entity remains untouched.
[Export, PartCreationPolicy(CreationPolicy.NonShared)] public class StaffingResourceSummaryViewModel : StaffingResourceScreenBase { private readonly ExportFactory<StaffingResourceNameEditorViewModel> _nameEditorFactory;
[ImportingConstructor] public StaffingResourceSummaryViewModel(IUnitOfWorkManager<IResourceMgtUnitOfWork> unitOfWorkManager, ExportFactory<StaffingResourceNameEditorViewModel> nameEditorFactory) : base(unitOfWorkManager) { _nameEditorFactory = nameEditorFactory; }
public async void EditName() { var nameEditor = _nameEditorFactory.CreateExport().Value; await nameEditor.Start(StaffingResource.Id).ShowDialogAsync();
StaffingResource.FirstName = nameEditor.FirstName; StaffingResource.MiddleName = nameEditor.MiddleName; StaffingResource.LastName = nameEditor.LastName; } }
|