Hmm... I do have to agree that using a separate class does open up
possibilities and help alleviate concerns. I was thinking of doing
something like that at first, but it didn't seem as "elegant." But
thinking about it more it does make a lot of sense, both for the ability
to create a more robust class, and to keep the "read only" contract
strictly enforcable.
What exactly is the "node specific introspection caching" mentioned in
the docs? Would it be worth it to put a class like this on the Context
tree, versus subclassing ArrayList or something like that to get more
functionality for free?
--
Patrick
Geir Magnusson Jr. wrote:
> "Patrick E. Whitesell" wrote:
>
>> Basically, I wanted to create a context chain where the most recently
>> created context was not necessarily at the head of the chain. These
>> changes allow me to do that.
>
>
> Well, there are alternatives. One thing that bugs me, beyond the chance
> that someone cooks up an infinite loop, is that you can't assume anymore
> that a context is 'read only' when chained, which I think is important.
>
> To illustrate, suppose you have a framework of some type that
> instantiates and populates a toolbox context, something containing
> common tools to be used by a request. By being able to 'add to the end'
> of the chain, you can effectively modify that toolbox. Not good. Yes,
> you can claim that you will remember to clean up, but I woudn't want to
> bank on it as a framework.
>
> An alternative, I think, would be a little helper Context that allows
> you to add contexts in any order, and insert them anywhere, but in doing
> so, doesn't assume anything about the contexts its working with.
>
> Instead of
>
> C -> ToolboxContext -> YourContext
>
> have
>
> C -> ToolboxContext
> |
> -> YourContext
>
> so you get the same result w/o fear of screwing someone else up.
>
> As a quickie example, suppose you had something like : (and forgive any
> gaffes - I am winging it here with beer in hand...)
>
> public class ContextChainer implements Context
> {
> private ArrayList inner = new ArrayList();
> private HashMap myData = new HashMap();
>
> /*
> * add context to the vector at some position
> */
> public Context addContext( int pos, Context c )
>
> /*
> * remove context from some position
> */
> public Context removeContext( int pos );
>
>
> /*---- Context interface --- */
>
> public Object get( String key )
> {
> // check local
>
> Object o = myData.get( key );
>
> if ( o == null)
> {
> // go through the list..
>
> Iterator i = inner.iterator();
>
> while( i.hasNext() )
> {
> Context c = (Context) i.next();
> o = c.get( key );
> if( o != null)
> return o;
> }
> }
>
> return o;
> }
>
> etc...
> }
>
>
> Now, the advantages here is that
>
> 1) you can place your contexts in any order
> 2) you can remove them as well
> 3) you don't modify anyone elses context
> 4) I don't fear a loop :)
>
> It also means that all sorts of interesting [goofy] constructs can be
> made :
>
> C -> ToolboxContext -> Toolbox2
> |
> -> YourContext
> |
> -> AnotherToolbox -> C1
> |
> -> C2
>
> Comments?
>
> geir
>
>
>> Geir Magnusson Jr. wrote:
>>
>>
>>> Could you provide some information what problems you were trying to
>>> solve, or what you are trying to enhance? That would be great.
>>>
>>> geir
>>>
>>>
>>> "Patrick E. Whitesell" wrote:
>>>
>>>
>>>> Hey fellas,
>>>>
>>>> I did some stuff to enchance the Context chaining. This is my first
>>>> submission, so let me know if I'm way out of line...
>>>>
>>>> There are some ugly bits in here due to the fact that the innerContext
>>>> is defined as a Context, not an AbstractContext. Does anyone object to
>>>> making the innerContext an AbstractContext? If not, I can take the
>>>> exceptions out of this code...
>>>
