Re: Making changes to EO after validation?
Re: Making changes to EO after validation?
- Subject: Re: Making changes to EO after validation?
- From: Ken Anderson <email@hidden>
- Date: Fri, 13 May 2005 13:22:07 -0400
I typically subclass EOEditingContext, override saveChanges, and
perform all of my object graph modification there.
In my saveChanges method, I would iterate over the changed EOs and send
them 'finalizeForInsert', 'finalizeForUpdate', and 'finalizeForDelete'.
I also keep track of what objects have received this message, and
re-iterate the object graph until all objects are hit (solving the
problem of a finalization call to one EO creating new objects or
modifying others).
Ken
On May 13, 2005, at 12:36 PM, Chuck Hill wrote:
I'm not really sure I want to wade into this :-) but...
First off, Anjo is dead on. You don't want to do this, you should not
want to do this, and the frameworks will fight you tooth and nail if
you try. validateForSave is the gatekeeper for the object store. Its
job is to ensure that nothing gets saved unless it has validated it.
Modifying the object graph after validateForSave() finished would
violate its very reason for existence.
As I see it, you have three options:
1. Do it in the component
2. Do it in the EO
3. Do it in another object
I agree that the component might not be the place to do this and I
also don't like to have my EOs call saveChanges(). You might want to
think of the third option, having some sort of ShiftManager object
that is responsible for overseeing the closing and opening of shifts.
It can provide information to the page on what is valid and what
options there are and it can handle the two phase save.
Before I did that, I would consider some other options. Here are some
ideas that might spark some of your own:
1. Defer reseting the cash box balance until the _start_ of the next
shift. The last time I was a cashier (thankfully long ago) that is
how it worked. You handed in your cash tray and discrepancy notes,
the boss shook his head and muttered. He then recorded all that
information. For the next worker, he then restocked the cash drawer.
Often that did not happen until the next morning.
2. Add a method to Shift like this:
public void close() throws ValidationException {
validateForSave();
cashBox().resetBalance();
}
and in your component
try {
shift().close();
ec().saveChanges();
}
catch (ValidationException v) {
// do the right thing
}
catch (EOGeneralAdaptorException e) {
// do the right thing
}
3. I had another one, but it has slipped my mind. :-)
Chuck
On May 12, 2005, at 6:59 PM, Stirling Olson wrote:
Hi,
I would like to make a change to an EO just AFTER it has validated
but just BEFORE it has saved to the graph/DB. Is this possible?
It appears an update goes something like this (I'm using Wonder):
willUpdate() -> validateForUpdate() -> validateForSave() -> SAVE ->
didUpdate()
What I really want is something like didValidate() which would happen
just before the SAVE. Any ideas?
To let you know what I'm trying to accomplish here:
I have Shift and CashBox EOs. When I try to close out a Shift and
Shift.endingCashBoxBalance != CashBox.balance the validation fails
UNLESS a discrepancy note has been added to the Shift EO. What I
would like to do is to update the CashBox.balance but ONLY after all
other validations have occurred and have been successful. This
allows for me to keep the "old" CashBox.balance until all other
validation problems have been cleared up. I can trick this behavior
in the components by saving twice (i.e. updating CashBox.balance and
then doing a second saveChanges() if the first succeeded) but what
I'm trying to do seems to me like a business logic problem and
therefore I'd like to put it in my EOs and not in the apps
themselves. FYI: CashBox is related to Shift through
Shift.cashBox().
I can't make changes to the EOs in validateForUpdate() or
validateForSave() according to Practical WebObjects, right? Any
other ideas other than the above suggestions in each and every
component which deals with this issue?
Thanks!
-Stirling
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
village.net
This email sent to email@hidden
--
Practical WebObjects - a book for intermediate WebObjects developers
who want to increase their overall knowledge of WebObjects, or those
who are trying to solve specific application development problems.
http://www.global-village.net/products/practical_webobjects
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
email@hidden
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden