Thanks Chuck !
it was mention to me a while ago, but didn't looked at the code
because I thought I was related (somehow) to a wothread and thus I
didn't see it fit what I had in mind.
From the doc :
* <code>ERXThreadStorage</code> provides a way to store objects for
* a particular thread. This can be especially handy for storing
objects
* like the current actor or the current form name within the scope of
* a thread handling a particular request. <br />
* The system property
<code>er.extensions.ERXThreadStorage.useInheritableThreadLocal</code>
* defines if the thread storage can be either inherited by client
threads (default)
* or get used only by the current thread.
But now that you mentioning it, I had to look at the code, and yes
90% of the implementation is there ... ouray !
It is almost what I had in mind, only that I don't want a different
map per thread, I need a single map no mater how many threads.
Why would we want a different map per thread when you use the editing
context as a key ?
When you receive a request (worequest), you have to set the map every
time, no ? (note that it's not worse than adding an entry for every
new eoeditingcontext)
I have to think about it ...
but it's already a great news !
Thanks !
- jfv
Le 07-04-04 à 23:57, Chuck Hill a écrit :
Hello Jean-François,
Take a look at ERXThreadStorage from Project Wonder. It is the
best solution to these sort of issues that I have seen.
Chuck
On Apr 4, 2007, at 8:47 PM, Jean-François Veillette wrote:
...
My next implementation at solving this problem will turn around a
common 'context' class that will have static methods to return the
current 'consultation' object given an EO (internally using the
eo.editingContext() has a key to map a consultation object).
Draft implementation :
public class Context {
HashMap contextHashMap;
public static Object context(Object ec) { return contextHashMap.get
(ec); }
public static void setContextForKey(Object ctx, Object key)
{ contextHashMap.put(key, ctx); }
}
Then somewhere early in Session constructor ... and/or anywhere I
create a new EOEditingContext I would do the same :
Context.setContextForKey(new
ConsultationObjectThatHoldMyBusinessLayerContextInformation(),
defaultEditingContext);
This is crappy code (we need a memory friendly implementation in
order to ease garbage collection of our context and key objects),
but you get the idea.
These are 2 working solutions (see my 2 first attempts at solving
this problem), so it is possible to solve it.
With so many brilliant WO developer around you will get a solution
that fits your mindset and your needs.
_______________________________________________
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]
