This is a constant issue with data binding on any platform.
Silverlight 3 does have an answer, in that they have a basic validation mechanism that is triggered by an exception being thrown when attempting to set the property. I haven't really explored it, as it is a pure UI thing (the value never gets into the object obviously), but it may be helpful for your scenario?
I've thought about making CSLA work with the SL3 validation model - and I still might do so in version 3.8.
However, there are some very serious and real limitations to the SL3 model that make it undesirable. This is because it is an exception-based model, not an interface-based model.
This means that it works by handling any exception thrown when the setter is called. Nothing more complex than that.
The result of this is that it can only display one error, not multiples. And since the setters aren't being called on dependent properties, the entire dependent property validation concept goes away (changing one property can't cause another property to be shown as invalid).
So I haven't gotten too excited about supporting their model, because it is not a good model, and it would cripple some nice features of CSLA.
On the other hand, maybe that's OK - and it wouldn't be that terribly hard to support. I'd just change CheckRules() to throw an exception on the first broken rule (probably ignoring all warn/info severity rules entirely) and to not process any dependent property rules.
Again, very far from ideal, and so it isn't real likely that I'll do it.
I haven't had time to look at the new Validation model but it had been on the back of my mind and I was waiting for a mention of it in the forums.
Can you not just set a 'reminderToThrowMSException flag', continue to process all the CSLA magic, then once you are done check the reminder flag and throw it? Obviously only if a flag to 'throw MSExecption' was set by the developer...
It does seem a lot like all the other 'wizard' tools - does something blanket for the simple basic CRUD related activities but if you want anything custom then its a pain in the butt.
jack
I can absolutely throw an exception in CheckRules(), that’s not
the hard part.
The hard part is that you’d STILL need to have the dual model
(SL and PropertyStatus) or dependent properties wouldn’t work.
And you’d lose info/warn severities.
And only one of the rules would actually appear in the
exception, even if several were broken.
I am currently having a problem with this issue where if an integer field is correctly populated (to show the accept button) then incorrectly populated with some text then the “accept changes” button is still available.
1. Is it possible to get the accept button to disappear with the Silverlight validation as well as with the CSLA validation?
2. I notice that you might be addressing this issue in CSLA 3.8 is this still the case?
3. Any idea when CSLA light 3.8 will be publically available?
I don’t know that SL validation can address that issue. Maybe it can, but I don’t know how.
I don’t think I’ll be addressing this issue in 3.8, because I don’t know how to address it. If the data type doesn’t match, the value never gets through data binding to the business object, so the object doesn’t even know that an attempt was made to change the value. CSLA lives at the object level, so it is entirely unclear that CSLA can do anything about this at all.
I’ll probably do a preview release of 3.8 to solicit feedback on some of the changes I’ve made to InvokeMethod and PropertyStatus late this week. I’m on vacation next week, and would like to get something online so people can play with it while I’m out of touch.
Rocky
Copyright (c) Marimer LLC