• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Best Practice on Uncommitted Changes in EC
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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
  • Follow-Ups:
    • Re: Best Practice on Uncommitted Changes in EC
      • From: Sacha Mallais <email@hidden>
References: 
 >Best Practice on Uncommitted Changes in EC (From: Kieran Kelleher <email@hidden>)
 >Re: Best Practice on Uncommitted Changes in EC (From: Sacha Mallais <email@hidden>)

  • Prev by Date: WebObjects Developer Opportunity
  • Next by Date: Re: Best Practice on Uncommitted Changes in EC
  • Previous by thread: Re: Best Practice on Uncommitted Changes in EC
  • Next by thread: Re: Best Practice on Uncommitted Changes in EC
  • Index(es):
    • Date
    • Thread