Actually, in this situation I could also postpone the RMI until after
the EO has been saved. Is there any way to tell if the EO has been
saved to the DB yet? Keeping in mind that the Client-Side EOF does not
include the EOAccess package.
Is ec.hasChanges() as fine-grained as it gets, or even needs to get?
Dave
On Apr 11, 2008, at 10:07 AM, Florijan Stamenkovic wrote:
On Apr 11, 2008, at 04:57, David Avendasora wrote:
It's a complicated function that steps through lots of
relationships adds up values.
Sounds like a regular PITA. Well, if you insist on keeping the
process on the server, I don't know of any other way you can do it
then the one you already do (except for the
eo.editingContext().validateForSave()) change...
Well, hypothetically, maybe, a derived attribute could be used, but
that is probably a worse solution on many levels...
What Anjo says, well, if the delegate would stop the editing context
from validation, but RMI would continue, it would still commit the
changes to the server, and you would end up with a possibly invalid
server side context. To me that does not sound good, and I believe
your idea of validating before triggering RMI is more appropriate.
Except, you might want to validate on the EO's editing context, not
the EO itself, because triggering RMI on the EO will save all the
changes in it's context.
However, I've never worked with editing context's delegates though,
and only assume about it's functionality, maybe Anjo had something
different in mind...
F
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]