Re: Using ERXEC with defaultEditingContext?
Re: Using ERXEC with defaultEditingContext?
- Subject: Re: Using ERXEC with defaultEditingContext?
- From: David LeBer <email@hidden>
- Date: Wed, 15 Oct 2008 11:03:51 -0400
On 15-Oct-08, at 10:38 AM, David Avendasora wrote:
I have a very similar question. I have a small, 3-component single-
user web application that does one business function. I had been
using session().defaultEditingContext() as my EC without any problem
(technical or business).
I have since made this app a Wonder app and have been slowly
AJAXifying it. I have not changed any of my calls to the EC. The
problem is that now I am having problems with WO trying to delete
things that have already been deleted from the DB and issues with
cascading deletes and owned objects not propagating the way they
used to.
I don't think it is an AJAX-specific problem as the issues started
happening prior to my adding AJAX to the app, but after turning it
into a Wonder app (extending ERXApplication, ERXSession, etc).
I just want to be clear on what you are saying. This is what I'm
hearing:
defaultEditingContext() should be okay for one user doing one
business function (includes creating and deleting many objects).
It's not good to use if your application has numerous business
functions that wouldn't make sense to have a save in one save the
changes in another.
Or is the default EC just plain bad for more technical reasons?
By using the session().defaultEditingContext() exclusively, you
consign ALL of your user's activities to one universal sandbox. If the
user aborts a task you are left having to cleanup their mess so their
changes don't end up getting accidentally committed to the db. There
are lots of ways to dirty the object graph (got onclick bound to a
form submit anywhere?).
If multiple ECs are used correctly, this is not an issue. A user can
abort a task and any changes they might have made will just go away
when the EC does.
I'm not sure if multiple ECs would solve your particular problems,
they sound more like backtracking or model related, but I use multiple
ECs as a matter of best practice for all my apps regardless of size/
complexity.
Dave
On Oct 14, 2008, at 11:18 PM, David LeBer wrote:
[Please keep replies on the list]
On 14-Oct-08, at 11:04 PM, Jeff Schmitz wrote:
Thanks, and just to be sure, no locking or unlocking at all if
just using these contexts within a single session and single
thread, right?
As long as you enable autolocking with the appropriate settings in
your app properties and always use the ERXEC.newEditingContext()
factory method to generate your new EOEditingContext.
<http://davidleber.net/?p=282>
On Oct 14, 2008, at 9:58 PM, David LeBer wrote:
On 14-Oct-08, at 10:51 PM, Jeff Schmitz wrote:
After some "thorough" research, I've decided I need to use new
ERXEC editing contexts instead of using the Session
defaultEditingContext everywhere, especially in cases where I'm
make changes to EO's. I had a question about the ERXEC
documentation. It states:
"... you will need to use this class and its subclasses
exclusively as your ECs, it also contains a factory class to
create editing contexts. ...
Does this mean, if I an ERXEC editing context, I can't use the
Session's defaultEditingContext anywhere in my application?
No.
If you are using Wonder and doing the 'using Wonder' things:
Your Application class subclasses ERXApplication
Your Session class subclassess ERXSession
Then your Session defaultEditignContext IS an ERXEC vended
editing context. Its magic that Project Wonder...
;david
--
David LeBer
Codeferous Software
'co-def-er-ous' adj. Literally 'code-bearing'
site: http://codeferous.com
blog: http://davidleber.net
profile: http://www.linkedin.com/in/davidleber
twitter: http://twitter.com/rebeld
--
Toronto Area Cocoa / WebObjects developers group:
http://tacow.org
_______________________________________________
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