I still think that I don't want per thread storage, we already
have request.userInfo for that and I use it only for web/request
related informations (used at the interface layer only).
The thread is valuable precisely for this, actually. Thread storage
lets you abstract away the "container". I don't have to pass a
WORequest around to get to its userInfo. Fundamentally what we're
all trying to do here is provide access to thread-global variables.
It's just the medium-of-transfer we're debating here. For instance,
we have some model objects that trigger notifications based on state
changes. Those notifications benefit from knowing who the user is
that is executing the change as well as information from the
WOContext that they came in on.
At the business layer (outside of a wo / rrl context) the concept
of thread doesn't hold as much (unless it's part of your business).
It contains as much meaning as the transaction (read: editing
context) that you're executing within. Potentially moreso, because
hanging on the editing context applies that the variable is scoped to
the transaction vs hanging on the thread implies it's scoped to the
thread of execution. That's purely academic, though. It's all about
"whatever works for you".
ms
_______________________________________________
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]
