Re: Child Editing Contexts -- locking/unlocking
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