"Multi-face" Contextualize

["Noel J. Bergman" <no...@devtech.com>]

> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
> > 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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>