The missing feature is Property Constraints. Inside the Eco model, each property actually has a Constraint collection but the modlr does not provide any access to it. I ended up using the Tag Properties collection to store them. Work fine but there is no pre-runtime way to validate your OCL.

Rick Weyrauch

Maybe that would be another good feature idea...... A call back interface on Verify Model where the application developer can say whether or not any non-Modlr OCL is still valid against the current model. Then, if I make some fancy-schmancy OCL based extension, I have an opportunity to run it against the model. Of course, I could make such a thing now but this callback would (should, could) have an IVerifyOclService that is already pointing at the model environment (Eco must have it for it self to verify OCL) that I could just toss my OCL at so that I do not have to do all the work of getting a "Verify the Model" environment setup.

Capable Objects - Aren't you glad I am back on the Eco bandwagon? Three new feature request a week! The problem is, it is so easy to love that I just want to love it to death!!!

Rick Weyrauch

Exactly this solution I would prefer no matter with persistance or not because it would give guarantee the object space is always in valid state.

It would be in a multi-client environment, but for single-client I make logically no difference between persisted and not (yet) persisted object. Why should I do?

/Efim

I had a look into IDataErrorInfo and must admit I'm not much impressed;-)

Quite simple - yes, but I guess suites for realtively simple validation cases one instance (property)

 <-> one possible problem. In any other case the information get lost when you e.g. concat 2 or more error messages in one string, not talking about other exception data as number, inner exception and so on. But the main problem with this approach, not specially concerning IDataErrorInfo is  that you need some smart decision rools that should be able to leave an invalid state and go to some reasonable valid one. The Undo is not necessary always the best choice as it can lead to deadlocks. 

I can agree if an invalid state is entered in an UI in "Idle"-state, your decision rule could be (and Is in most cases) a User that is smart enough to find the best choice. But what if not? That is why  I used not to allow invalid states in an application in general, but rather to take care about always valid transitions between states.

It is better not to do sins than later regret and try to correct these isn't it?;-)

/Efim

If it is possible to keep a user from entering into an error condition by disabling a button or control, I will do so explicitly in the form. The prevention logic is different from the constraint logic. The constraint logic indicates an error condition exists. Whereas the prevention logic indicates that an action/command will cause an error condition. A robust application needs both.

WPF has a nice concept where commands call a CanExecute method to determine if the command can be executed. The logic that determines the CanExecute should be programmed in the domain object. So the CanExecute event code should call into the domain object to determine the result.

It would be very nice if we could bind the wpf commands to the eco domain object. Rick has done some things interesting things to accomplish this. Maybe he could chime in.

Brian

The only consideration of using constraint logic on the model level for me is multi-client architecture - it is because you can never be sure your data are correct indeed before you save these in DB.

/Efim

Right now the sample is over at C.O. getting "looked at" for a little issue I had with it. As soon as we can resovel the issues I will post the sample here.

Rick Weyrauch