> From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED]] > > 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.
Keep in mind what the purpose of services and information are. A service acts on information, provides information, or changes information. In both FOP and POI, you have a complex document format, and relatively few services. That is fine. Let your services focus on *doing*, and your document format focus on representing the document. One of the issues with trying to componentize (which is what you are really talking about) is that too many people try to make the *document* or *information* into components. Those don't make good components--and you are finally finding out the hard way why not. The ResourceManager works by fetching information so that you can use it and interpret it or embed it in your finished document. What you want is a DocumentBuilder service (or something like that) that will be the entry point for FOP/POI, that will generate a document in a stream format. In fact you guys might be able to come up with the same interface. No matter how you decide to do it, you will most likely deploy the "builder" pattern. In FOP you would typically have an adaptor that writes the information to the stream, as well as a builder that assembles the document from the incomming XSL:FO document. Beyond that, the internal services that you would use might vary tremendously. The best rule of thumb is to focus on the services acting on your document model. And above all DO NOT HAVE an ACTIVE document model. The Document should be passive, built by external services, or altered the same way. > 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? There is no reason for that. It is your Document Object Model > 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. I assume by "projects" that you are referring to "objects". Like I said above, adopt a proper design pattern like the "builder" pattern, and when the time comes for the ImageFactoryService to be used, the builder accesses it. Or perhaps it is not the builder that uses it, but the adaptor that serializes the information to a stream. Either way, it is used by the proper service. > How can I make these components serviceable? Do not make services out of objects. > Should I? No. > It seems that when the model becomes too finegrained, the Avalon > patterns become difficult to use. That is because you are thinking in pure OO terms. You need to stretch and think in terms of services/components. > Comments, ideas? See above. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
