Stuart Roebuck wrote:
>
> On Tuesday, July 31, 2001, at 01:47 pm, Berin Loritsch wrote:
>
> > Stuart Roebuck wrote:
> >>
> >> I'm trying to pin down a problem with components in Cocoon 2 at the
> >> moment
> >> and was trying to get to grips with Avalon. I ran across the following
> >> code which didn't look like what I was expecting...
> >>
> >> "hasComponent()" which seems like a benign test, has the side-effect of
> >> 'releasing' a component and appears to rely on "release()" not raising an
> >> exception as the basis for determining the component's existence:
> >
> > It relies on the select() or lookup() function to not throw an exception.
> > It
> > could be rewritten to take advantage of the internal structure, but this
> > approach
> > is both future proof (it does not break if you reimplement the lookup() or
> > select() functions) and correct. There is the possibility of trying to
> > embed Objects that are not Components--which effectively removes the
> > ability
> > to get the Component.
>
> By 'lookup()' do you mean 'release()'? There doesn't appear to be a
> lookup() function/method.
No. by lookup() I mean the equivalent method in the ExcaliburComponentManager
as opposed to the ExcaliburComponentSelector.
> But it still seems to me that if you call hasComponent() using the hint
> for a component that has already been 'selected' then that component will
> have been released by the time the hasComponent() method returns.
That is the whole idea. We are not returning the Component. That is what
the select() method does. We are returning whether it is possible to get
a component for that hint.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]