(cc: stefano because I used his name in vane)
Peter Donald wrote:
> 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).
>>
We do? I don't. Wrapper it with an avalon thing, but I'll -1 the hell
out of any attempt to make the bits and pieces avalonized. And I'll fly
over to Italy and beat you (nkb) with a wet noodle if you mark anything
with LogEnabled in POI. Its inappropriate IMHO in a low level API.
SoC = that which wraps or needs poi to fit it into its own component
extraction. POI just needs to worry about reading and writing the file
formats it works with, not about fitting into any particular component
model. (We have folks who have asked to turbineize it too). If Morphos
is Avalonized or the HSSF Serializer that makes sense. The API does NOT
make sense avalonized. POI should have as few dependancies as possible
as what it is concerned with is VERY limited (by design). (I can't take
credit for that...thank Stefano -- I disagreed with him at the time but
I see his wisdom)
At one time we thought it made a lot of sense to make POI use log4j so
that we could leave lots of tracing info in it for autopsies (if POI
couldn't read/write a file and died, we could trace its life). But
what happened when people tried to deploy POI with their existing log4j
application that used a different version of log4j? Death and
destruction and for want of deploying something that they wouldn't want
to log in production anyhow (1000x slower).
(and we tried commons logging but it didn't really solve that problem)
So What would happen if you tied it to Avalon? Same thing. Someone
deploys POI with a different version of whatever Avalon pieces and in
the words of Marvin the Marshian kaboom.. an Earth shattering Kaboom.
So in short APIs stay APIs. Things which need them as components get
component wrappers. The dependancy tree stays clean.
>
> 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.
>
-1 While wrapping it is fine. Making POI APIs depend on Avalon is just
silly.
> 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?
>
-1 - Wrapping makes sense. Heck if I were writting an application that
I deemed it appropriate I'd wrap it in Components and Services. But not
in the core API. NOT everything tht CAN be avalonized should be. Less
is more.
-Andy
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
