Re: Best Practice on Uncommitted Changes in EC
Re: Best Practice on Uncommitted Changes in EC
- Subject: Re: Best Practice on Uncommitted Changes in EC
- From: Kieran Kelleher <email@hidden>
- Date: Fri, 8 Apr 2005 16:12:33 -0400
Let's say I am in edit mode on a new/editing Account transaction and
the user decides to click on Account (to go to a list of account
transactions and forget saving the new or edited Transaction), what I
am currently doing is:
1) Get a reference to the entity (Account)
2) Make another new EC and make a local instance of the Account entity
3) Call revert on the new EC to eliminate any unsaved changes on the
local instance (such as relationships between Account and the
Transaction if it was a new transaction)
4) Push the Account reference into the new page and go to that page.
Is this all a bit "heavy handed" or is there a better standard
practice to prevent a dreaded failure of a later save due to an
"invalid/incomplete" entity lying around??
Is there any reason you are avoiding calling revert() on the old EC?
I was thinking about doing that, but thought that this would be bad for
the case where a user backtracks to that unsubmitted edit page that
used to have a new entity that disappeared after the revert, so I
thought that leaving the edit page behind with the new uncommitted
entity in an isolated EC would be safer. Does that make sense?
I don't think it's "heavy handed": creating a new EC on every page
isn't excessive.
Is it OK to be creating new EC's (letting the wonderful
MultiECLockManager manage them) every time the user goes to an edit
page and leaves that edit page without committing changes?
Sure, why not? It often makes more sense to create a new EC instead
of reusing an old one.
sacha
--
Sacha Michel Mallais - 400 lb. chimp
Global Village Consulting Inc.: http://www.global-village.net/
1. Never tell everything at once.
-- Ken Venturi, Ken Venturi's Two Great Rules of Life
_______________________________________________
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