> From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED]]
> > From Noel:
> > > Berin:
> > > > As impacting Framework 5+, I would like to see a flexible context
> > > > that has very strong contracts--i.e. if you want a BlockContext,
> > > > you get one with no casting, if you want a ServletContext
> > > > same thing.
> > > If there is such a solution, I'm for it, too. Do you have
> > > a suggestion that is BOTH strongly typed AND extensible?
> > Personally, I don't like castings, and anything that can make it less
> > "scary" I like. Hence I think your idea is interesting.
> > I like using the service classname to ask for a service to the
> > servicemanager, but some like opaque keys. Hence the above
> > example can be applied there too.
> If Avalon components can have a universally extensible lifecycle,
> we can substitute Contextualizable for whatever we want
> (like BlockContextualizable).
Are you proposing an interface pattern where if a container knows about T
Contexts and an object exposes an TContextualizable method then the
container will call that method during the Contextualize lifecycle phase?
This would be similar to the way that JSP <jsp:setProperty ... property="*"
/> works. The JSP container knows what named values are in the request, and
it introspects the bean to see if the bean has a property of that name,
e.g., the bean has the appropriate setter method.
I view this as a variant of the Java Bean pattern where the type of object
(TContext) is used as the property name, and we (at least currently) have a
different naming convention for the setter (TContextualize instead of
setTContext). At the risk of coining a term, I'll refer to this as a
"multi-face" pattern.
--- Noel
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
