• 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: Child Editing Contexts -- locking/unlocking
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Child Editing Contexts -- locking/unlocking


  • Subject: Re: Child Editing Contexts -- locking/unlocking
  • From: Chuck Hill <email@hidden>
  • Date: Thu, 4 Aug 2005 09:06:26 -0700

Some additions to David's comments:

On Aug 4, 2005, at 8:59 AM, David LeBer wrote:

On 4-Aug-05, at 11:47 AM, Dana Kashubeck wrote:

I'm sorry if this is noise, but I've never worked with anything but the defaultEditingContext before and I want to make absolutely sure that I'm doing The Right Thing here.

I'm working on a wizard-like interface that resides in a framework. The user may be creating several new EO's that they decide at the end they don't want. Therefore, I don't want to put them in the defaultEditingContext when they are created because I don't want any changes to make their way there and get saved accidentally on some other page (all of our WO apps use defaultEditingContext exclusively).

Perhaps not the best plan WRT memory usage / session size.


  I figured this is a perfect place for a child editing context.

I'd be looking more at a peer EC, possibly with a child EC for each page of the wizard if you need to revert just what is on that page without affecting the changes made on other pages.


The first page will create the child editing context (defaultEditingContext is it's parent), fault in some needed objects from the defaultEditingContext, and put it into a userInfo dictionary in the Session. Each subsequent page will grab the child editing context from the session in it's init method.

Why tie the page to the Session like this? Have the wizard pass the object(s) being edited along to the subsequent pages, the EC will follow along.


Now, as long as I don't perform any sort of fetches or changes on EOs, etc. in the init method, I can simply lock the child editing context in each component's awake method and then unlock it in the corresponding sleep method, right?

No, there are pitfalls in that approach. See Practical WebObjects 83 - 93 or the list archives.



Also, I have to lock the newly created child editing context before faulting in the objects from it's parent, and then unlock it afterward, correct?

At least for that if not more.

Chuck


Thanks in advance for your help!

In general you are better to lock EC's in the session (if you've got one) rather than the component.


As that is the usual approach, there are a couple of solutions to implement that for you:

MultiECLockManager: <http://wocode.com/cgi-bin/WebObjects/WOCode.woa/1/wa/ShareCodeItem? itemId=301>

Project Wonder's ERXEC: <http://wonder.sourceforge.net/javadoc/er/extensions/ERXEC.html>

--
;david

--
David LeBer
Codebase Software Systems
site:   http://www.codebase.ca
blog: http://david.codebase.ca


_______________________________________________
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:
This email sent to email@hidden


  • Follow-Ups:
    • Re: Child Editing Contexts -- locking/unlocking
      • From: Dana Kashubeck <email@hidden>
References: 
 >Child Editing Contexts -- locking/unlocking (From: Dana Kashubeck <email@hidden>)
 >Re: Child Editing Contexts -- locking/unlocking (From: David LeBer <email@hidden>)

  • Prev by Date: Re: Child Editing Contexts -- locking/unlocking
  • Next by Date: Re: Framework EOModel Question
  • Previous by thread: Re: Child Editing Contexts -- locking/unlocking
  • Next by thread: Re: Child Editing Contexts -- locking/unlocking
  • Index(es):
    • Date
    • Thread