Re: EditingContext question
Re: EditingContext question
- Subject: Re: EditingContext question
- From: Chuck Hill <email@hidden>
- Date: Thu, 15 Apr 2004 09:14:33 -0700
Child editing contexts are useful for multi-step wizard like
functionality and some other odd UI designs. In general, peer is
easier to use.
Chuck
On Apr 15, 2004, at 8:25 AM, Jonathan Rochkind wrote:
The one further thing I'd add to this good explanation is: After
thinking about it, I don't really see any reason to use a child EC,
instead of just a peer EC (create with "new EOEditingContext()"). I
used to use child ECs, largely because Apple used to have a reference
page that reccomended them. But about a year ago I switched to using
peer ECs, and have been overall happier with them. It's a bit simpler
and easier to understand than the 'child-parent' EC design, and seems
to meet all the same needs Tom describes below and work just as well
if not better.
--Jonathan
At 9:24 PM -0700 4/14/04, 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.