all,
I've been working on a project where I tried to keep basic functionality
separate from all the cool stuff in framework (some of the people I work
with feel intimidated by the hard copy of the site I dumped on their
desk, so... ;), then extended/ encapsulated that functionality into
avalon-framework-based components.
This turns out to be quite a bit of effort, especially since you're
writing stuff from scratch, you already know avalon framework and know
it won't have a negative impact whatsoever depending on it (especially
as we're moving away from marker interfaces).
As the code is stabilised, I found myself following the patterns
completely, only without actually implementing the framework interfaces;
then creating wrappers consisting of
MakeComponentXAnAvalonEnabledComponent implements Contextualizable, etc
{
contextualize( final Context context )
{
// copy avalon context into custom context
// ...
contextualize( myCustomContextThatDoesNotDependOnFramework );
}
}
That said, some projects dislike the fact that they get a dependency on
avalon framework when they get an avalon component. Some of the stuff in
excalibur would be in wider use if avalon framework were an optional
dependency instead of a required one.
While that is stupid, it is something we have considered in the past
when writing stuff. Maybe we shouldn't.
I tend to view avalon framework like I view java.lang -- its always
there. Whenever I use COP, I use avalon; that's the most natural way to
do it, in my world anyway.
just thoughts; reaction welcome but not required ;)
- LSD
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
