"Patrick E. Whitesell" wrote:
>
> The only methods that would have to be added to Context would be
> getChainedContext() and setChainedContext(). AbstractContext could
> still have loop detection but other implementations wouldn't need to.
> If the interface supported getting and setting the next context I could
> still do full loop detection in AbstractContext, but iteratively as
> opposed to recursively.
There is nothing that says that AbstractContext has to be used :)
'Context' is what a context implementation has to support.
I have another msg coming... still writing... hang on 2 min...
geir
>
> --
> Patrick
>
> Geir Magnusson Jr. wrote:
>
> > "Patrick E. Whitesell" wrote:
> >
> >> Well, how averse are you to adding to the Context interface?
> >
> >
> > I think it depends. Making every context impl support this kind of
> > advanced chaining isn't something that I think I would support w/o some
> > convincing.
> >
> > Will respond to other post with alternatives discussion.
> >
> > geir
> >
> >
> >> Geir Magnusson Jr. wrote:
> >>
> >>
> >>> "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...
> >>>
> >>>
> >>>
> >>> And yes, w/o thinking much about it, my first reaction is that we want
> >>> to keep it general as a Context, rather than the AbstractContext. This
> >>> should keep things more flexible for chaining arbitrary contexts. At
> >>> least that's the idea...
> >>>
> >>> geir
--
Geir Magnusson Jr. [EMAIL PROTECTED]
System and Software Consulting
Developing for the web? See http://jakarta.apache.org/velocity/
