On Mar 7, 2009, at 8:34 AM, Mike Schrag wrote:
You are right there. But the value is only stored for inspection.
Nothing depends on it and it's only to satisfy my client that
want's to know who wrote/modified what (it's an online newspaper).
In other words it is perfectly fine for it to be empty if I ever
used it from outside of my webapp. If it where only for the
timestamp I could rely on specific db features like MySQL's ability
to auto set the timestamp. But I need the user as well.
How does ERXThreadStorage work? What can I assume to be in the same
thread?
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).
I used to do that nasty EC stuff as I could not see another way. Now
that I have found ThreadLocal religion, I never use that malignant
hack. I think of the information stashed in the thread as an
ExecutionContext (similar to a WOContext). That feels like the
"right" solution to this common need. I've even created an object to
aggregate the bits under one object. This is also very useful for
recording things like user activity (set into the thread / execution
context by the UI component) so that you you can not only record who
and what and when, but why as well.
ThreadLocal (ERXThreadStorage). Good stuff!
Chuck
--
Chuck Hill Senior Consultant / VP Development
Practical WebObjects - for developers who want to increase their
overall knowledge of WebObjects or who are trying to solve specific
problems.
http://www.global-village.net/products/practical_webobjects
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
