On Tue, 3 Sep 2002 19:34, Nicola Ken Barozzi wrote:
> I'm doing some work on Avalonizing FOP, as it has been decided it's the
> right way.
>
> We are using already LogEnabled, and now it's time for Configuration,
> but most important of all, usage of the SourceResolver.
>
> Now, I'm dealing with a problem I already had with POI (we want to
> avalonize it too probably).
>
> When we have big object pacakge structures and classes, it becomes
> somewhat impractical to use IoC.
>
> For example, in POI there are tons of classes that represent portions of
> the OLE2 file format.
> Shall I have all of these become container-components?
>
> Or in FOP: there needs to be an ImageFactoryService, but the problem is
> that it needs to be used by projects deep in the call stack.
>
> How can I make these components serviceable?
> Should I?
>
> It seems that when the model becomes too finegrained, the Avalon
> patterns become difficult to use.
>
> Comments, ideas?
It is hard to give a good explanation without knowing either system well
enough. However I would generally recomend that if it does not "feel" right
to do something then it probably isn't. Which means you either needs some
rearchitecturing of the application or need to not use Avalon at that level.
Let me use the POI components as an example. I know absolutely zero about them
so ignore any of the glaring inaccuracies ;)
The classes in POI represent bits of OLE2 file. Presumably they are passive
(ie they just hold data) or they are reactive (they just "react" to method
calls on them). In the first case, Avalon interfaces have no place being part
of the object. In the second case I would tend to pass the relevent services
in via the method parameters.
So rather than
OLEThingieMaJig tmj = ...;
tmj.enableLogging( logger );
tmj.service( sm );
tmj.doStuff();
I would do
OLEThingieMaJig tmj = ...;
tmj.doStuff( logger, sm );
or preferrably
OLEThingieMaJig tmj = ...;
MyRequiredService myRequiredService = ...;
tmj.doStuff( logger, myRequiredService );
or maybe
OLEThingieMaJig tmj = ...;
MyRequiredService myRequiredService = ...;
try
{
logger.debug( "Pre-doStuff" );
tmj.doStuff( myRequiredService );
logger.debug( "Post-doStuff" );
}
catch( SomeException se )
{
logger.debug( "Somexception occured!", se );
}
You will notice that the last version knows nothing about avalon. You will
also notice that as I went down through the examples, less and less work was
placed on the shoulders of the OLEComponent and more and more work was placed
on the shoulders of container of OLEComponents.
However this may seem like a lot of work - especially if there is no real
notion of containers for the objects (or the containers are other
OLEComponents).
In which case I would create a set of active/behaviour orientated classes.
Something like OLEComponentVisitor. These "behaviour" components I would
strongly recomend use Avalon interfaces if you can.
So I guess my recomendation would be to separate passive (ie data holding) and
active (ie behaviour orientated) objects and restrict your Avalonization to
the active objects. If this is not possible for whatever reason I would tend
to pass the needed resources into the behaviour bits (ie methods etc).
If that is still not possible then I would recomend creating another API layer
for working with the low level components. Perhaps a good idea would be to
use something like
interface OLEContext
{
Object getMyMagicStuff();
int getOtherStuff();
String performMagic(String someParam);
}
OLEComponent.myMethod( OLEContext ctx );
And after doing that for low level components would restrict avalonization to
high level service orientated/or pluggable components.
Not sure if that hepled any?
--
Cheers,
Peter Donald
Doubt is not a pleasant condition, but certainty is absurd.
-- Voltaire
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
