wood burning stoves 2.0*
The moose likes OO, Patterns, UML and Refactoring and the fly likes Pattern for Handling Confirmations? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "Pattern for Handling Confirmations?" Watch "Pattern for Handling Confirmations?" New topic
Author

Pattern for Handling Confirmations?

Robert Wright
Greenhorn

Joined: May 01, 2002
Posts: 19
I am looking for some design pattern ideas for handling confirmations that are needed by potentially unsafe middle-tier business processes.

In the case of stock confirmations such as "Are you sure you wish to delete X?" that are always displayed, these are simply programmed into the UI. However there are some warnings that are generated in the middle tier and need to be passed back to the UI so that the user can read the warning and indicate that he wishes to perform this potentially unsafe action. There is also the potential that a process could generate more than one warning that need to be overridden.

Let's say a sales person places an order that would put someone over their credit limit. The sales person tries to enter the order and a warning is displayed that the order goes over limit. He indicates that he wishes to place the order anyway. Then a warning appears that an item in the order is out of stock and has no anticipated delivery date. The sales person indicates that he wishes to bypass this warning as well and the order is then placed.

There needs to be some sort of conversation here between the middle tier and the front end regarding these warnings and confirmations. The middle tier needs to pass the warning back to the UI. Doing this as an exception is the obvious way to do it. But then the IU needs to communicate to the middle tier business logic that the warning has been displayed and that the user wishes to proceed in spite of the particular wrinkle(s).

Can anyone point to a pattern that applies here? Keeping business logic and presentation separate is essential here.
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
"conversation" in your last paragraph is what jumps out. We usually like true "service" components to be stateless. To carry on a conversation they have to know a protocol and remember what they've already said to make sense of what the client says next. I once had to call a service like this that kept state in session beans and passed a session bean handle around kind of like a cookie. It made for pretty complex client side code and I hated to imagine the service.

I guess you could copy the browser-server model and keep all the state in a cookie-like object that the client never examines or modifies. The cookie could track which validations have been passed, which triggered the last warning sent to the client, etc. I'm still not getting any happy feelings about it though. How about you?


A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Justin Chu
Ranch Hand

Joined: Apr 19, 2002
Posts: 209
    
    1
You can encapsulate the conversational state in an object and have it passed to the middle tier service? The middle tier can update the state and return it to the client. The client can update the state object and retry the invocation.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Mhh, it sounds a little bit like all the conversation could actually happen before you start with the actual processing of the request? In that case, it sounds very similar to a validation process, doesn't it?


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Robert Wright
Greenhorn

Joined: May 01, 2002
Posts: 19
>>Mhh, it sounds a little bit like all the conversation could actually happen before you start with the actual processing of the request? In that case, it sounds very similar to a validation process, doesn't it?

Yes it does, and that brings up a good point. I could require that programmers of the business logic processes look for these problems up front, before processing begins.
Robert Wright
Greenhorn

Joined: May 01, 2002
Posts: 19
>>"conversation" in your last paragraph is what jumps out. We usually like true "service" components to be stateless.


Yes, "conversation" does present some problems. I have stateless session beans serving as the gateway to the middle tier so I can't really keep up with any sort of "conversation" there. Cookies are a pill but I am using JSF so I have a lot of persistent objects where I can stuff things.

One idea I had was this:

Webapp calls the back end. Back end throws a "MissingConfirmationException" when it sees a potentially dangerous operation. The exception contains the error message along with a key that identifies the confirmation uniquely.

Webapp displays the error message and the user gives an 'OK' on the confirmation.

Webapp makes up a "Confirmation" object with the key inside and passes it as a param into a new method call. The back end code looks into the "Confirmation" object and sees that the dangerous operation is OK and does not throw the exception a second time.

I was thinking about having this Confirmation object being passed back and forth with each call for multiple errors but Ilja's point about it being like a validation process argues for having the back end check for all such problems up front which would mean that if the process generated multiple confirmations they would all come back at once and could be confirmed at once.
Robert Wright
Greenhorn

Joined: May 01, 2002
Posts: 19
>> You can encapsulate the conversational state in an object and have it passed to the middle tier service? The middle tier can update the state and return it to the client. The client can update the state object and retry the invocation.

Yes this is a good idea. I have been thinking in this direction.
 
 
subject: Pattern for Handling Confirmations?
 
Similar Threads
Cleared Part I today with 79%
Pattern for Using Dialog screens
Clarifications for Architect Part II Exam
body-content for tag files, classic and simple tags
Is it a good idea to put business logic in domain/model objects ?