Partially valid business objects

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".

13 comment(s)
John Botibol

Hi Oliver. Here is an example:

You have an application for administering the business of running training courses. You schedule a course and add tutors and rooms to it. When adding a tutor (or room) you present tutors in such a way to show their availability. You may assign an unavailable tutor (all sorts of reasons why you would do this in real life). When saving the course, you do a tutor availability check and ... warn the user if they are unavailable.

Bear in mind that courses are being scheduled and adjusted all the time so tutor availability is in a state of constant flux, hence the reason why you want to issue the warning when saving the course record even if you have done nothing to the tutor (i.e. perhaps you changed the course dates etc.).

Hope this fits the bill :-)

25 March, 2008
Oliver Sturm (DevExpress)

Hi John,

Thanks for that example. I guess it fits the bill - somewhat. It's certainly another scenario that requires consideration, but obviously there's still a bunch of important functionality required that doesn't have to do with checking a certain state on save.

Right now I'm actually thinking that the best solution to this problem is an interactive functionality as opposed to something entirely automated. When you create the course, you are more or less aware that your tutor assignment is only preliminary, pending confirmation by the tutor (or whoever), right? So it seems to me that you'll need a EngagementConfirmedByTutor flag anyway, because it's part of your workflow that this will be set at a later point in time. Then of course you might want functionality to find courses within the next two weeks that don't have that flag set - which you could currently do by creating a filter in a grid or by executing a specific report.

As I said, another example that's certainly different from my own Order/OrderLine thing. Can't say I have considered it carefully enough yet, but at a glance it does seem that this doesn't quite hit the spot either.

25 March, 2008
Riyaz Qureshi

IMO some of this functionality can be achieved if we were able to implement DXErrorProvider with XAF business classes.


25 March, 2008
Mohsen Benkhellat

One scenario that can happen in our application (cost control) is having an interface (Oracle Time and Labor) process could import timesheets filled up by users and save them in our database before cost control users update those timesheets with cost oriented additional data like which assignment they involve and what rates etc. Only then timesheets are ready for other processing.

I can see (just my opinion) that a state property on a BO could be very helpful given that from its creation to its deletion, a BO goes through multiple transformations (state among others). I can think of an extension to XAF validation framework using some kind of configurable WorkFlow to decide whether an object has reached a given state (like valid) or not and eventually act on that object (by modifying its properties).


25 March, 2008

Other possible scenario can be seen in an inventory system. I have created a system that implements serialization and deseralization process to store a group of items into a field in a datatable. The partially valid business objects is present when a transfer movement is realized. The invoice is saved but the existences has NOT updated after a reference number from the target subsidiary is injected. Obviously manage an state solved this request (IN PROCESS, WAITING REFERENCE, etc.). In this scenery... XAF can manage the serialization of items too?



25 March, 2008

Hi Oliver,

Do you think that this potentially useful feature is being clouded by the term partially *valid*. I am not sure that has much meaning - something is either valid or not. The scenario you have described I have implemented in the past with something like an unauthorised / authorised status flag. That way, "partially specified" orders such as the one in your example cannot be saved if they have an authorised status (but can if it is unauthorised).

A scenario that I have encountered that might fit the bill is related to orders and cross / upsell products. If the user enters product A that has an associated cross sell product B (i.e. the business would like the customer to order B as well since is complements A), then the user could be prompted that that there are unentered cross sell products. The order is valid either way but the warning is letting the user know that it could be more fully specified from a commercial perspective.


26 March, 2008
Gary Short (DevExpress)

Hi Oliver,

I have come across this partially valid scenario before in an order entry system I worked on. In theory, if a user creates an order for immediate delivery, and then tries to add an item that is not in stock to that order, then he should be prevented from doing so, as the order can no longer be delivered immediately.

However, the customer commissioning the software, knew that his stock control system was not perfect and so wanted the order to be accepted as "partially valid" until a physical check was made to ensure that there was indeed no stock of that particular item. At the point of the physical check the order was then marked as "fully valid" because there was stock, or "invalid" as there was no stock.

Hope this helps.

26 March, 2008

Not sure this is the example you are looking for but in an app we are now working on we have a "Grant Agreement" which must go through a Committee. At least 3 "Committee member" from a pool of 9 must provide comments and rate the Grant before the Grant Agreement can move to the next stage of the workflow.

I see partially valid objects when different users must complete the object and obviously they cannot complete the object at the same time.


26 March, 2008
Mark Krasnohorsky

Hi Oliver,

I was prompted to log this suggestion based on a need that arose while working on an application for a client, and also some general theory on business application design.

First, the application does implement a "partial" valid methodology with a final review screen prior to the release of the data to the next process. So, you are correct in the sense that it is "ultimately" handled.

So, why the warning?

Some background on the application. The customer delivers mulch to clients a full truck load (100 cubic yards of the stuff) per delivery. In the summer standing in the dispatch office, one just gets stressed by watching the absurd high level of activity.

Each order has a customer, ship location, destination location, and a product based on those four relations we can establish a per yard delivery price.

The customer, location and product data is managed at head office, while the coordination of trucks and dispatch functionality is done at one of the remote offices in the field.

The users who are dispatching trucks, only care that they know what truck is going where and what product is being delivered. They do not particularly care if the customer, location or product is defined in the master data, and with the extremely high volume of deliveries, there just isn’t enough time to properly define the information.

I solved this problem by creating a new lookup editor that is based on the MRU edit, I populate the MRU items list from a collection of customers, locations or products. This way a dispatch functionality has the benefit of selecting a pre-existing item or typing in a new one if a pre-existing one does not exist.

So, first need for warning. Products are linked to customers. So the product list is populated based on the customer selection. If the dispatch user selects a customer that is not pre-defined, the product list may appear to be empty or missing some items. At this point I thought it would be a good feature to show a warning message whenever a customer field represents a customer that is not pre-defined, this gives the end user a very quick feedback as to why the product is not appearing. (Of course, this would imply that validation would have to happen at field level not at save level, which I think it should do as one of the default contexts, but it was relatively simple enough to do via a controller so I did not log a suggestion for that, although I would love to see it at field level)

The second scenario is more based on a philosophy of business application functionality. My belief is that often a business application is nothing more than a digital representation of an existing paper based system that the company is automating. With paper you get the benefit of a margin, and also the ability to enter “invalid” data without anyone telling you what to do. Of course this sword cuts both ways. Now, when I design systems, I design them such that, the user to whom the data is relevant is responsible for making sure the data is correct. I believe that often the person doing data entry does not care about certain validity rules, while the person approving the data does. So, very often I design my business transactions objects with partial validity and an approval screen to attain complete validity, as opposed to doing a hard “cannot save” validation.

(As an aside, the other scenario is say it is 4:55 PM, I am in the middle of entering an order, and I just want to go home, so I want to save and leave, but the system prevents me, so I put in dummy values (without thought) probably making the problem worse than if there were no values because now there is a “valid” order in the system).

However, it turns out that there are people who care about the process and the company, and they would like to know when they are making a mistake. So, by providing a “soft” validation with a warning, the employee can chose to fix the mistake (if he/she knows what the mistake means) or find out how to fix it. This provides an interesting way for training, where a user acquires more knowledge about what a valid order is etc... without being prevented from doing his or her core job.

Thank you,


27 March, 2008
Oliver Sturm (DevExpress)

Cesar - if I understand your description correctly, you should be able to do your "serialization" on the XPO level. The best thing for you to do is probably to contact our support team with a little more detail information, and they should be able to point out some resources to you.

28 March, 2008
eXpress App Framework Team

Thanks to everybody for your comments on my post Partially valid business objects , they are most appreciated

28 March, 2008
Trevor Westerdahl

The partially valid state can be much more simple (IMO). For example, assume we have a RexEx pattern to validate an Email address. Sometimes a strict enforcement of the pattern is not required.

Simply put: the user can save anything, but will get a warning if the RegEx pattern fails.

As far as more complex scenarios: take a general ledger transaction - they should all balance - period. However, a glitch, or an error, or some other scenario may allow an unbalanaced transaction to take place. Thus, an unbalanced GL entry must be made in order to correct an entry. In this scenario, it would be unwise to simply allow a user to enter unbalanced transactions without warnings, but necessary to allow a 'partially valid' transaction - as in - the user would get serious (annoying) warnings that they are creating an unbalanced transaction.

Exactly how to handle such scenarios is unlimited; however, I do see that "warnings"  - actions that inform an end-user that something is not normal, yet will still be allowed is mandatory (IMO) for any framework design. Validation that is on/off only and that restricts or allows only seems too limiting.

29 March, 2008
eXpress App Framework Team

This is post no. 3 in the mini series "10 exciting things to know about XAF". You can find

25 January, 2012

Please login or register to post comments.