> From: news [mailto:[EMAIL PROTECTED]] On Behalf Of Andrew C. Oliver > > >>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.
Andrew, there is no need to grandstand on this list. If you want to dispute the componentization of POI then do it on that list. Do not spout your objections here, it is not the appropriate list. > 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) Sure, POI should have as few dependencies as possible. However, if proper componentization of POI makes sense for POI, then I suggest you don't throw the baby out with the bath water. The suggestions we provided don't necessarily mean you have to use Avalon, but it very well may cause POI to have a cleaner and more robust design. > 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) And how does this relate to the _Avalon_ list? > 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. This is strawman rationalization and pure FUD. Have you used Avalon? We avoided 90% of the issues that caused Log4J and Commons Logging to fail. The fact that you say this crap means you have no clue what Component Oriented Design is or affords you. The truth is that as long as the service interface (i.e. how you use a component) remains the same, then it doesn't matter which component implementation you use. It will *still* work. Keep in mind that this is true of whatever component architecture you use--whether you want to invent your own or use one that exists (like Avalon). > So in short APIs stay APIs. Things which need them as components get > component wrappers. The dependancy tree stays clean. Again, this is not related to the Avalon list at all, take it up on the POI list. > > 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. Take it up on the POI list--I don't care about your infightings as long as it doesn't infect our list. > -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. How the h-e-double-hocky-sticks do you propose to wrap with components something that is not originally a component? If you want to reuse existing components, you have to design for components. It's that simple. Beyond that, take it off this list. I don't care about your objections to POI API changes, this isn't the POI list. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
