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: Sacha Mallais <email@hidden>
- Date: Fri, 8 Apr 2005 13:26:46 -0700
On Apr 8, 2005, at 1:12 pm, Kieran Kelleher wrote:
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?
Good planning, but be careful: if the user, for example, deletes the
account then backtracks to the new/edit account transaction page,
you've got a really inconsistent EC that will give your app
conniptions. Pretty much any page that changes the state of your
application is going to cause trouble if you allow backtracking. By
contrast, query- and display-only pages can be backtracked over without
problem...
sacha
--
Sacha Michel Mallais - 400 lb. chimp
Global Village Consulting Inc.: http://www.global-village.net/
Choke on that, causality! -- the Professor, "Futurama"
_______________________________________________
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