avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew C. Oliver" <acoli...@apache.org>
Subject Re: [FOP Avalonization] IoC the holy grail?
Date Tue, 03 Sep 2002 22:34:37 GMT
+1 totally on unit tests.  This is the chief path to quality and not 
breaking things or having them break silently.

-andy

Paul Hammant wrote:
> 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:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>


Mime
View raw message