Re: EditingContext question
Re: EditingContext question
- Subject: Re: EditingContext question
- From: Tom Blenko <email@hidden>
- Date: Wed, 14 Apr 2004 23:48:32 -0700
The two reasons I can think of for using a child (or nested) editing
context are
1. You have data in the parent (presumably default) editing context
that you want to use in the child ec you have created, e.g., to relate
existing EO's to one you have just created. If you don't use a child
ec, I'm pretty sure you wili have to refetch the existing EO's. There
are situations in which that cost is undesirable.
2. I believe that creating the editing context without the parent will
replicate at least part of the EOF stack. Seems less than desirable but
I've never seen it become an issue.
Neither of these may be very important in your situation.
Locking is available to prevent two application threads from accessing
the same structure, in this case the ec. This is probably not a concern
for you. You'll want to implement lock/unlock to eliminate endless
messages in the log from WO warning that ec's are being used unlocked.
awake()/sleep() are suitable places to do that.
Tom
On Apr 14, 2004, at 10:23 PM, James Cicenia wrote:
Thank you for the information! What I was just doing was creating a
new EOEditingContext... placing that into my session
and then referencing that ec for the subsequent operations. I figured
that would eliminate the two saves. What is the problem
with that approach? Also what locking code are you referring to during
the awake and sleep and why is it necessary?
Thanks again,
James Cicenia
On Apr 14, 2004, at 11:24 PM, Tom Blenko wrote:
The issue you describe arises regularly in WebObjects and it's an
instance of a more general problem.
Suppose the user enters the 'order' section of an application, starts
to construct an order, and then navigates off the order section
without completing/committing the order. S/he then manages to perform
some other operation that causes the Session's default editing
context to be saved, e.g., by updating his/her user profile. An EO
inserted into the default editing context during creation of the
order might be saved unintentionally.
The solution is to use a child editing context on the page where the
new EO is created. A child editing context 'inherits' from its
parent, which is typically the Session's default editing context.
EO's can be fetched into the child editing context and updated or
deleted, and new EO's can be inserted. All these operations are
performed transparently to the rest of the app.
If the user abandons the page, the child editing context is collected
along with the page and its contents are lost to the rest of the app.
On the other hand, if the user, e.g., pushes the Save button on the
page, saveChanges() on the child editing context propagates its
contents to the parent. The usual pattern in a save() method is to
saveChanges() on the child and immediately saveChanges() on the
parent, causing the changes to be written back to the database.
If the lifetimes of the new EO and its child editing context may span
multiple pages, as they might on an order site, you will have to make
them available to all pages from which they (might) be used. Passing
them from page to page is one approach. Binding them in the Session
is another. Naming this state a 'shopping cart', or something
suitable, in the Session will probably keep you off the radar of the
software engineering police.
I've heard developers claim that child editing contexts are too much
trouble. They're really not, you can often add one line to an
existing to page to create the child of the default editing context,
make sure all references to an editing context on the page refer to
the child, add a saveChanges() for the child right before any
saveChanges() for the parent, and then add two lines to lock and
unlock the child on awake and sleep. Not bad, especially if you cut
and paste from an existing page. Sometimes, you may also have to
fault EO's from the parent ec into the child (one line of code
apiece).
Tom
On Apr 14, 2004, at 7:00 PM, James Cicenia wrote:
Hello -
I want to know what is the best way to handle "open" editing
contexts?
In other words, I have a user launch a window with a different
editing
context to edit the specific object. Now, when I spawn this window I
create the new object, insert it into the editing context,
initialize and then
pass it to the nextPage which in this case is a popup.
How do I handle the person closing the window and not using my
cancel?
This new object will still be in the editingcontext which is session
based.
Should I just call a "revert" before launching any of my windows?
thanks again,
James Cicenia
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.