RE: When (not) to use session().defaultEditingContext()
RE: When (not) to use session().defaultEditingContext()
- Subject: RE: When (not) to use session().defaultEditingContext()
- From: <email@hidden>
- Date: Fri, 29 Oct 2004 13:18:02 +0200
- Thread-topic: When (not) to use session().defaultEditingContext()
Ben,
I actually have a user object associated to my editing context in order to keep an audit log.
Actually the user object is held by an instance variable in my EOEditingContext subclass. The subclass' constructor takes a User object for argument and creates the appropraite local instance. No need to worry about when to create a local instance.
Actually, I also work with editing context factories which know the User object instance held by the session's default editing context. Whenever asked for an editing context, the factory hands out an instance of the EOEditingContext subclass initialized with the USer object.
No code other than the factory and the audit trail code need to know or care about the User object. UI code just needs to ask the session for its EC factory and the get an EC from the factory.
P.S. Of course every application has its own needs. An editing context use strategy should be defined with those needs in mind.
Pierre
-----Original Message-----
From: Ben Ketteridge [mailto:email@hidden]
Sent: Friday, October 29, 2004 12:01 PM
To: Pierre Bernard
Cc: email@hidden; email@hidden
Subject: Re: When (not) to use session().defaultEditingContext()
On Fri, 29 Oct 2004 11:45:56 +0200, email@hidden
<email@hidden> wrote:
> I advocate creating fresh editing contexts as often as possible. I.e. each time you
> start a procedure that's logically independent of what was done previously. E.g.
> when the user submits a search query. The editing context gets carried on from
> there to the result list, the detail pages, ... but is not reused for another search.
> (Run a search for 'trails' on the webobjects-dev mailing list over at OmniGroup)
Your strategy is all very well if your transactions are truly
independent. However, we have a User object that lives in the Session
- it therefore lives in the defaultEditingContext. Hanging off the
User object are relationships that restrict the User to doing work for
particular Clients within the system. This Client is then used to
create Sales Orders - and all of a sudden we have to do work to make
sure that user interactions do calls to localInstanceOfObject all over
the code to ensure that we don't accidentally put the User's Client
(in the defaultEditingContext) into a relationship from a SalesOrder
(in a transaction-specific editingContext).
There is more to the decision on which editingContext you use that
simply stating 'always create a new one'. I would have to add the
caveat, 'where you're not depending on objects in another one.'
Ben
--
| Ben Ketteridge email@hidden, aka Gremlin |
| It is by caffeine alone that I set my mind in motion. |
| It is by the coffee that the thoughts acquire speed, |
| the lips acquire stains, the stains become a warning. |
| It is by caffeine alone that I set my mind in motion. |
**********************************************************************
This email and any files transmitted with it are intended solely for
the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the sender
of this message. (email@hidden)
This email message has been checked for the presence of computer
viruses; however this protection does not ensure this message is
virus free.
Banque centrale du Luxembourg; Tel ++352-4774-1; http://www.bcl.lu
**********************************************************************
_______________________________________________
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