Partially valid business objects

XAF Team Blog
25 March 2008

This suggestion made it into our user story planning for XAF 8.2:

There are times when one wants to inform the user of some sort of problem with the business logic, but an error (preventing a save of the object) may be too strict. It would be beneficial to show the user a warning so that the user can have his/her attention drawn to it, but not be prevented from saving the object.

I was thinking about this and right now I'm not sure if we're going to do it - probably not for 8.2, I guess, since it definitely needs further consideration. Anyway, I thought it would be good to blog about this, to explain my thoughts and perhaps get some additional feedback on it.

First I was trying to come up with a scenario that fits the description given in the issue. The one thing that came to my mind was an ordering scenario: a customer gives the phone operator a few details about an order, but not all of them, since they want to complete the order at a later point, they are undecided or whatever. Now, when the Order object has already been created, but (for example) no OrderLines have been filled in, this might be regarded as a "partially valid" state, which satisfies the description above. This scenario is quite representative in some parts, but not quite so in some others... read on.

My initial reaction to that problem is that if the "partially valid" situation is expected in the workflow of the application user, then I would solve it in a different way. I have two ideas about this:

  1. I could add an "Incomplete" flag to the order object
  2. I could store data for incomplete orders in a different type - "IncompleteOrder" comes to mind. For usability reasons, I would implement a few actions in XAF that allow the user to start writing an Order in the Order detail form, then change his mind to save it as an IncompleteOrder instead. Or the other way round of course - convert an existing IncompleteOrder into an Order object when the customer has made his mind.

In spite of these arguments I pondered the idea of integrating with Validation further. If I was assuming that the "partially invalid" state was expected, what use would it be to show a warning to the user when saving? Most probably the user would already be aware of the state at that point. Displaying a warning would really make sense if the user was surprised by the fact that his data didn't satisfy all validity requirements. Or rather, not all of them - just those that are "not quite as important" as the "real" requirements. I tried to come up with a scenario that fits this new description, but I couldn't. If you can, please let me know - perhaps there's something entirely new to the whole story when given a real-world example.

Now, assuming we implemented a variety of the Validation process that would allow to check for partially valid state. The developer would implement some checking function that would find whether the state is satisfactory or not. I guess this resemblance to the way Validation works is really why Validation was originally mentioned in the issue. Would that work? I'm not convinced - in my scenario of Orders and OrderLines, what if the user has actually entered some OrderLines for the Order, but the customer still said to hold off with the order another day? How would the automated checking code be made aware of that fact?

Great, so say we have a state checker and we trigger it in contexts similar to Validation - would that be sufficient? No, I don't think so. We could find out on Save that there's a partially valid state and show a warning of arguable relevance. But what then? Surely the user would be interested to find those partially invalid objects among all his others later, right? So we'd have to implement another block of new functionality that runs checks all the time and displays visual feedback in list views. But of course there would be other functionality in the application that deals with the partially invalid objects - one prominent example would be reports. So we'd have to find a way to integrate with that other functionality, basically perform some filtering based on certain state, but since the information about that state is not available from the object itself, it would require a "sideways" extension of the whole data binding functionality. Hm...

So this is my point of view right now: implementing this based on Validation is a major problem, because it leaves lots of open questions and a minefield of problem cases. I can see that there are theoretically two different types of situations that involve partial validity, one of them in expected cases and the other in unexpected ones. I couldn't come up with an example for the unexpected case, so that point might be moot. Under any circumstances, the solution that involves a flag or a separate class seems a good one - not only is it pretty clean in the expected case, it also doesn't have any of the problems with application functionality that the Validation based solution seems to have. And the "flag" solution could even be used in unexpected cases - standard Validation can find (partially) invalid objects and deliver a message to the end user saying basically "your data is invalid, either correct it or check the Incomplete flag".

Free DevExpress Products - Get Your Copy Today

The following free DevExpress product offers remain available. Should you have any questions about the free offers below, please submit a ticket via the DevExpress Support Center at your convenience. We'll be happy to follow-up.
No Comments

Please login or register to post comments.