Notifications

[ConvertFromOldNGs]

by Craig Shearer >> Mon, 26 Jun 2000 23:00:52 GMT

Hello All

I would be interested in feedback on the following. In my app I cause user notifications and I generally have a method on some class to cause the event, eg:

notifyOfferStatusChange(offer: Offer);
begin

causeEvent(Notify_OfferStatusChange, false, offer);
end;

However, notice that the second parameter is false, meaning that the notification will be delivered at the end of the transaction. This is what I want, however I can't guarantee that the method will be called while in transaction state (unless I write all the code that calls this method). The result is that if the method is called outside of transaction state, then the notification won't be delivered until the end of the NEXT transaction. (At least, this is what the documentation says)

Perhaps a better way to code this might be:

causeEvent(Notify_OfferStatusChange, not process.isInTransactionState, offer);

which would mean that if the process is in transaction state then the notification will be delivered at the end of the transaction. If not, then it will be delivered immediately.

Comments?

Craig.

[ConvertFromOldNGs]

by Krull >> Thu, 29 Jun 2000 3:03:34 GMT

Hi Craig,

If your intention is that this event should always be associated with succesfully committing a database transaction, I would be tempted to make process.isInTransactionState a precondition, i.e. add something along the lines of the following to your original method:

if not process.isInTransactionState then
raiseNotInTranStateException();
endif;

However, on the surface it appears unusual that you would need to actually publish such a method. It doesn't appear to be a method you would want users of your class or framework to call out of context i.e. the method call could be encapsulated - correct me if I am wrong.

[ConvertFromOldNGs]

by JADE Kid - Ray Hidayat >> Tue, 4 Jul 2000 21:29:57 GMT

That sounds like a better idea, because you would only call that method during transaction state wouldn't you?
If you didn't, something would have gone wrong.
And I sort of understand that encapsulated means that you can leave a class on its own, and it is not co-dependant, so you can extract it and put it in another schema...
But from what I see, I'm sure that this notification method would be called from a form that has just updated something.
So I don't think that it is encapsulated.

--
Ray Hidayat
JADE Kid - 2000
www.jadekids.com