• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: EditingContext question
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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.


References: 
 >EditingContext question (From: James Cicenia <email@hidden>)
 >Re: EditingContext question (From: Tom Blenko <email@hidden>)
 >Re: EditingContext question (From: Jonathan Rochkind <email@hidden>)

  • Prev by Date: Re: EditingContext question
  • Next by Date: Re: Direct Actions in Components
  • Previous by thread: Re: EditingContext question
  • Next by thread: Re: EditingContext question
  • Index(es):
    • Date
    • Thread