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 protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
