Re: EditingContext question
Re: EditingContext question
- Subject: Re: EditingContext question
- From: Tom Blenko <email@hidden>
- Date: Wed, 14 Apr 2004 21:24:45 -0700
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.