Re: EditingContext question
Re: EditingContext question
- Subject: Re: EditingContext question
- From: Jonathan Rochkind <email@hidden>
- Date: Thu, 15 Apr 2004 10:34:36 -0500
At 12:23 AM -0500 4/15/04, 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?
Ooh, sorry I'm sending so many messages on thsi thread, but: I don't
think there is any problem with this approach. I think it is in fact
preferable to creating a child editing context---you're right it
eliminates the dual save---and in most aspects works just as Tom
describes, but simpler. It is in fact what I do. I don't think you
need a child EC, I think a "peer" EC, created just by doing "new
EOEditingContext();" is perfectly sufficient.
Also what locking code are you referring to during the awake and
sleep and why is it necessary?
All EOEditingContext's need to be locked and unlocked (with methods
lock() and unlock()) around any use of them---including use of any
EOs in those ECs. The session default editing context is locked and
unlocked for you by the WO framework. Other ECs you create yourself,
whether "child" or "peer", you need to handle locking for.
I wrote a class which makes it very easy to set up a system where
your own created ECs are basically "automatically" locked and
unlocked for you much like the session default EC. I've been using it
myself in a deployed application for over a year and it seems to work
fine. You can get the code at:
http://wocode.com/cgi-bin/WebObjects/WOCode.woa/wa/ShareCodeItem?itemId=301
--Jonathan
PS: I really reccomend against sending to all the lists at once.
Repliers to your messages, like me and Tom, not liking spamming all
the lists, may trim the addresses from replies. But one when one
replier chooses one list, and another chooses another list, now you
wind up with different sub-threads spread accross different lists.
Just send to one list.
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.