Re: Digging up a Session object from an EOGenericRecord
Re: Digging up a Session object from an EOGenericRecord
- Subject: Re: Digging up a Session object from an EOGenericRecord
- From: Riccardo De Menna <email@hidden>
- Date: Sat, 7 Mar 2009 17:57:51 +0100
On 07/mar/09, at 17:34, Mike Schrag wrote:
Whatever you put in it ... It's a ThreadLocal place to shove data,
so you can push the current user (or current user GID) into it. You
really shouldn't access the Session from model classes, it's just
bad form and eventually there's good odds you're going to regret
it. Also, putting the current user into ERXThreadStorage means that
you don't have to worry about other code making new editing contexts
where your state isn't setup. I've seen several people subclassing
EC's to add custom app state, but for me, it misrepresents what an
EC's role is, and invariably leads to weird issues (like the local
instancing into other ec's, etc).
Yes I can see your point there. I can't really force every line of
code not to use my EC. Like for instance all the mess I wrote to
detect/climb the parentObjectStores.
BTW... don't bother to answer my question 2 on my previous msg. I
already stumbled in the obvious. Having nested the contexts means that
when I save, data is not propagated to the db as it sits waiting for
the original ec to be saved as well. And that's clearly not feasible.
My question is rather about the scope of the thread. The docs speak of
"scope of a thread handling a particular request". It dies on each
request so you are implying that I should populate it with my data on
a session "awake" call for example?
rdm
_______________________________________________
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