Re: [Wonder-disc] NSUndoManager is Mandatory for any EOEditingContext
Re: [Wonder-disc] NSUndoManager is Mandatory for any EOEditingContext
- Subject: Re: [Wonder-disc] NSUndoManager is Mandatory for any EOEditingContext
- From: Chuck Hill <email@hidden>
- Date: Thu, 22 May 2008 10:33:55 -0700
On May 22, 2008, at 8:53 AM, email@hidden wrote:
Hello fellow WOrriors,
How can I get an account to update the confluence wiki at the
following link:
Try the "Contact Administrators" link in the page footer. Though that
is a plain WO page and not a Wonder page (you sent this to the Wonder
list). I will copy wo-dev.
http://wiki.objectstyle.org/confluence/display/WO/EOF-Using+EOF-Memory+Management#EOF-UsingEOF-MemoryManagement-NSUndoManager
The advice given regarding EOEditingContexts and their NSUndoManager
is well-meaning but wrong.
1)
===============================
I have found that doing:
editingContext.setUndoManager(null);
Will create the following error when you attempt to delete and save
an EO that has a delete rule of "deny" on an existing relationship
(using WO 5.3):
java.lang.RuntimeException: java.lang.IllegalStateException: Editing
context needs an undo manager to recover from delete propagation
problems. Do not set the undo manager of this editing context to null.
Yes, you need the undo manager if you have delete rules, esp deny rules.
2)
===============================
Additionally, if I try the following:
editingContext.undoManager().disableUndoRegistration();
I find that little undo / redo pieces are still allocated in
memory... which defeats the purpose of removing registration. This
can be verified with a tool such as Jprofiler, etc. Any tool which
allows you to view the java heap and memory allocations.
Yes.
3)
===============================
After reflecting on notes #1 and #2 above, its safe to say that the
NSUndoManager is an integral part of the EOEditingContext and should
neither be crippled nor removed. Calling the following after saving
changes, as currently recommended in the wiki, might make sense:
editingContext.undoManager().removeAllActions();
That is what I do. I have an EC subclass that calls this after a
successful super.saveChanges(). That way, I don't have to remember to
do this.
but, in the same breath, we should also recommend that "dispose()"
might want to be called and explicitly setting the editingContext to
"null" if the editingContext is no longer needed. But, if that's the
case, there is no point even worrying about the undoManager in the
first place.
That depends on how the EC is used and how long it is kept around.
Chuck
--
Practical WebObjects - for developers who want to increase their
overall knowledge of WebObjects or who are trying to solve specific
problems.
http://www.global-village.net/products/practical_webobjects
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden