Gnarly design problem - how to identify all controls in an application (typically before they ar
So theys wants me to design and implement and application wide validation system for a rather complex set of interdependent properties. Obviously this will be easier in WPF than in Win32, but still rather complicated.
The why is too much to get into here, but basically I need to be able to predetermine all of the data bound UI controls in an applicaiton. Even those that have not yet been displayed.
Do I have the ability (at run time - app load) to extract all the UI pages and parse them to figure out what controls exist in the app?
I also need to identify the containing UI element (as perceived by the user).
For what its worth, all the controls that I am interested in will be mapped to ObjectDataProviders that I implement. However, this is not on a one-to-one basis, so it would only be useful in identifying in a general sense (bound to one of my biz objects) the controls that I am concerned with.
Any insights, suggestions appreciated.
I strongly recommend against that approach:
1) You want to keep the UI separate from the data. Leave the XAML clean and let different UIs operate on the same data.
2) Place the validation in the objects the UI displays so it is a clean separation of presenation and content.
3) You can place a layer of data objects between the controls and the "real" data objects to do this. This is the Model-View-ViewModel pattern that came out of the Sparkle project and is a logical extension of the MVC pattern. Place "UI" logic in its own layer just as you place "Business" logic in a separate layer.
4) With this approach the WPF controls are all clean, the UI logic is sepate from the business logic, and you can use data binding from WPF to UI and from UI to Business layers. Each layer is decoupled from the others and tied together with data binding specified in XAML.
I would agree with Micheal's points.
The only other thing that I would add, is if this was my project, I might break each control into a WPF usercontrol into itself.
I have a Point of Sale project underway and this has been helpful for me to "deconstruct" and debug a complex set of interactions.
Good Luck,
Alan Painter
Techwood Group
Hi Michael, thanks for the thoughtful response, perhaps I was a little misunderstood. I've actually been working hard at keeping business logic away from presentation logic/code. I plan on using the WPF validation model (validation rules, converters, data bindings, etc.) as the cornerstone of my basic input validation system. Each UI control will be bound to a discrete underlying object which interacts with the appropriate business rule objects. My problem has to do with validating across multiple controls and adorning them properly.
Unfortunately our system has a lot of complex, interdependent properties such that changing the value of property A) can invalidate a previously good value for property B) and they may live in different parts of the UI. Also, because there are situations where the user must enter an invalid state to get to a valid one, we have to allow them to at least enter (not commit) values that are invalid for the system as a whole even though they may be valid in and of themselves. So, I can't just apply a simple validation rule that applies to one little island of data and be done, I have to also apply validation from a broader context.
In other words, there are multiple levels (scopes) of validation, there is simple input and range verification (eg. "a" is not a valid int), which WPF seems to support very well. But then there are validation dependencies and business rules, which require the consideration of inputs in a much larger context that doesn't necessarily fit in one piece of UI.
I believe that I CAN accomplish the validation portion using the WPF validation model, whilst maintaining the UI/Business logic separation that I require. The notification side of things is where it gets difficult. I have a very specific design requirement that we provide aggressive notification (adornment) of invalid data, to keep the user informed when they are creating invalid situations. WPF let's me do this at the XAML page level, but I need to provide it at an application level as there may be multiple UI chunks (XAML pages) displayed at the same time.
That is what drove me to ask the original question.
I suppose I could have stated the specific problem: How can I adorn a UI element according to an external validation change (which may or may not include user interaction with a different UI element)?
What I want is comparable to having two separate UI constructs in different XAML pages that both two-way bind to the same data source. If the source changes, both targets reflect the change. In my case, I have a shared state of validity (albeit one that sits at a level higher than simple input validation). I want both UI constructs to reflect changes to that state of validity with the appropriate adornments. In a nutshell, I'm being asked to implement a notification that bubbles up to the display to indicate a change in validity resulting from an external input.
It occurs to me that I can accomplish this fairly cleanly via data-binding for any controls that are in existence/displayed. That may have to be good enough for the design folks.
Does this explanantion make more sense?
Thanks
NIK
What you describe is what I would have expected from your first question. You want to control the UI at the application level in more detail than is usually called for:
1) By using an application object that fronts the business data you can do any coorelation or complex validation logic you like and still tie it all together with bindings and events.
2) Your designers deal with the UI support objects in XAML and almost never see the "real" business objects that they proxy for. This way the isolation is complete as you already intended.
3) You can hang "validation" logic on any field using XAML that consults the UI front objects for thier complex logic. What that will not generally handle is making something invalid that used to be valid. To do that you need to be able to force a revalidation of the old input. The easiest way to do that is trigger a change to the value from the binding. If value A changes and impacts the validity of B and C signal a change to B and C from your UI front object. I have not tried this, but I would hope that the validation system will revalidate the value at that point. If not you can manually control the display of validity by binding that aspect of the control to the UI front object validity test.
This is all a bit general, but I think it will help you get where you want to go. The goal is to have stock controls bound to UI objects that have the complex UI logic for things like validation and presentation, and business objects that are pure business data. Check out the blog posts on the web on View-Model-ViewModel where there is more detail.
I think we're on the same page.
The gnarly part is trying hang notifications on top-level UI constructs (closed panel, or menu item) to indicate that there is a problem underneath that needs to be addressed.
Id like to implement it in a generic way in code, but I may just have to provide the support objects, educate them on the XAML and make it the designers responsibility to deal with knowing which controls are where and how to bind up the validation objects properly and adorn the top level constructs. Which is ok, because it is strictly an application display/logic issue then, which is there domain.
Thanks again for the insight.
NIK
