commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert McIntosh <rob...@bull-enterprises.com>
Subject [jelly] Scope revisited
Date Thu, 13 Mar 2003 22:48:17 GMT
First, is anyone currently working on an implementation of scopes? I 
know there has been talk, but don't know about any action.

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/ReadMsg?listName=commons-dev@jakarta.apache.org&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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message