Re: EditingContext question
Re: EditingContext question
- Subject: Re: EditingContext question
- From: Jonathan Rochkind <email@hidden>
- Date: Thu, 15 Apr 2004 10:36:54 -0500
At 12:17 AM -0700 4/15/04, Tom Blenko wrote:
3. When you saveChanges() on the child editing context, you are
updating the default editing context (assuming that is the parent)
with its changes. If you instead make changes in an independent ec
and saveChanges(), the database gets updated but you remain
responsible for seeing that any other part of the application
running with the same Session that needs access the updated dataset
gets it.
I don't believe this is so. I'm pretty sure that when your peer EC
saves changes, and commits to the database: various notifications end
up being passed around the EOF stack, and all the other ECs in your
application instance (including ones in the same session, of course)
will be notified of the changes saved and merge them in. I think
everything works fine here, and the problem identified by Tom does
not exist.
--Jonathan
So you might have to check for changes or refetch data or come up
with something clever. WO has some support for this (but it doesn't
always do what I expect),. You might be able to slug it out but... I
favor simplicity.
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.
_______________________________________________
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.