Re: EditingContext question
Re: EditingContext question
- Subject: Re: EditingContext question
- From: Chuck Hill <email@hidden>
- Date: Thu, 15 Apr 2004 09:11:08 -0700
When an EC saves all other editing contexts in the same EOF stack are
updated. Project Wonder has support for updating all EOF stacks in an
instance. I think Anjo Krank posted a link to this a week or so back.
Chuck
On Apr 15, 2004, at 8:36 AM, Jonathan Rochkind wrote:
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.
_______________________________________________
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.