If not, I'm willing to take a crack at it. I looked at the scope implementation used by the workflow project, which Craig had suggested in a previous thread on this subject (http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]&msgNo=22077), and it seems it would work quite well for jelly, possibly even doing a direct port to Jelly. With that thinking, a couple of questions come to mind:
1. I'm not entirely sure of the reasoning behind using int identifiers for the scopes, but that is ok with me. I can see how it is useful in the HTTP request, session, app scopes where you want a definate path to search for though. I'm guessing that jelly would mostly use named scopes(?)
2. Have/keep the scope listeners and events?
3. It looks as if workflow's context system doesn't have parents like Jelly's does, so the question comes up of where should the scope live when added to a context, or what is the scope of the scope :-). I'm thinking that it would be at the childmost level, unless a scope was added to a specific parent. If an item is added to a scope at a child context level, it would first ask it's parent if the scope exists and if so set the value there, otherwise create the scope at the child context level and apply the value there. Make sense?
4. Along the same lines as 3, this referrence, http://jira.werken.com/secure/ViewIssue.jspa?key=JELLY-1, shows the possiblity of nested scopes. If this is the case, does this cause extra search time for a given context to find a given scope if both are nested?
Thoughts?
~Robert
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
