Joined
·
19,572 Posts
Actually my next topic only covers point 1 and 2. Point 3 shouldn't be a problem after you get the first two. Sadly i've had small time recently due to the fact that i'm preparing all the stuff for the upcoming update this friday at work. The good news is that i have holidays for over 2 weeks so i have to get all things ready till friday to avoid having to work on my holidays if something goes wrong(so far everything going smooth). At the same time i'm preparing the base of our upcoming bit winter update. So i think you will have to hold your breath few days more but is going to pay off i believe.
First of all the Manager is basically an example i made of how you can manage main viewmodels. Basically you have to implement that interface on the main models that will hold your information(not list of childs for example). Using a converter you can freely bind viewmodels stored on your manager directly in XAML giving you a lot of flexibility when displaying information. Using the manager you can also request or hook up to any main viewmodel and listen to value changes regardless of the parent or hierarchy.
Validation can be easily done in the viewmodel base... one way could be using interfaces to declare what has to be validated. Meaning that before sending messages from the viewmodel base you can validate values first using each viewmodel validation implementation which returns a boolean to whatever a property is allowed or not. Another way to validate values is by using the "Set" of each property and apply a validator to determine whatever a property is allowed to change at a certain time unless all rules are met. You can easily do that by preventing "SetProperty(ref yourProperty, value);" to be executed or as i previously said apply your validation using interfaces in the viewmodel base SetProperty method which is the center of every property change. In other words... if you applied my concept correctly every single change in your logic MUST go through the "SetProperty" method in the ViewModelBase class before it does something. That is the right place to do anything required to allow or prevent changes.
First of all the Manager is basically an example i made of how you can manage main viewmodels. Basically you have to implement that interface on the main models that will hold your information(not list of childs for example). Using a converter you can freely bind viewmodels stored on your manager directly in XAML giving you a lot of flexibility when displaying information. Using the manager you can also request or hook up to any main viewmodel and listen to value changes regardless of the parent or hierarchy.
Validation can be easily done in the viewmodel base... one way could be using interfaces to declare what has to be validated. Meaning that before sending messages from the viewmodel base you can validate values first using each viewmodel validation implementation which returns a boolean to whatever a property is allowed or not. Another way to validate values is by using the "Set" of each property and apply a validator to determine whatever a property is allowed to change at a certain time unless all rules are met. You can easily do that by preventing "SetProperty(ref yourProperty, value);" to be executed or as i previously said apply your validation using interfaces in the viewmodel base SetProperty method which is the center of every property change. In other words... if you applied my concept correctly every single change in your logic MUST go through the "SetProperty" method in the ViewModelBase class before it does something. That is the right place to do anything required to allow or prevent changes.
