Ahh - forget everything I said. Berin said exactly what I wanted to say but better! Drat it ;)
On Tue, 3 Sep 2002 22:58, Berin Loritsch wrote: > > 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. -- Cheers, Peter Donald ---------------------------------------- Whatever you do will be insignificant, but it is very important that you do it. --Gandhi ---------------------------------------- -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
