• 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: Dana Kashubeck <email@hidden>
  • Date: Thu, 04 Aug 2005 12:17:30 -0400

Chuck Hill wrote:

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 was a bit concerned about that . . . planned to see what sort of memory footprint I run into.


  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.

Can I still fault in objects from the defaultEditingContext? The reason I ask is that the WOSession subclass that we use has several methods that grab information from the database using the defaultEditingContext. I'd really like to not rewrite that subclass. I would need to fault into the peer editing context some objects that I've obtained from the session. Can I do this or should I just do my own fetch and not use the session's methods?


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.

I thought I had read that chapter correctly, but I will re-read it. Thanks.

--
-------------------------------------
Dana Kashubeck
Systems Manager
Riemer Reporting Service Inc.
http://www.riemer.com

Phone: 440-835-2477 x. 125
Fax:   440-835-4594
-------------------------------------


Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

 _______________________________________________
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: Chuck Hill <email@hidden>
References: 
 >Child Editing Contexts -- locking/unlocking (From: Dana Kashubeck <email@hidden>)
 >Re: Child Editing Contexts -- locking/unlocking (From: David LeBer <email@hidden>)
 >Re: Child Editing Contexts -- locking/unlocking (From: Chuck Hill <email@hidden>)

  • Prev by Date: Re: Reusable Component Tricks...
  • Next by Date: Re: Child Editing Contexts -- locking/unlocking
  • Previous by thread: Re: Child Editing Contexts -- locking/unlocking
  • Next by thread: Re: Child Editing Contexts -- locking/unlocking
  • Index(es):
    • Date
    • Thread