Nicola, My only comment in addition to that of the others is that make sure you write unit tests for each component as you refactor. At work we have written a an AbstractPhoenixTestCase that pretends to be Pheonix for testing of a component. Now, that is just for Phoenix and perhaps you default impl for FOP should be a home-grown container tightly coupled to FOP and in FOP's codebase. Either way, if it is lifecycle aware, it will be similar to the AbstractPhoenixTestCase we wrote (but can't submit to Apache CVS). With Unit testing, or more accurately integration testing, you will be able to prove that as you refactor, things continue to work. It will help the bravery aspect drawn from XP.
Good luck & will love to see the product. - Paul > 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? > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
