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.
Yes, but object shave methods, not only data...
> 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.
Ah, ok.
The fact is that The OM is basically reactive, in a sense that the data
structure is able to reply to methods, which are used by the builder via
a common interface for all objects.
How do these methods get hold of common library services?
The common solution is use of static stuff, like in log4j, where to log
inside these data structures I get a logger via the static method.
It's a cross-cutting concern, so I cross-cut the hierarchy via static
methods.
>>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
This is what I thought of too, now I'm more confident it's right :-)
>>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".
Yup.
> 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.
Ahhh...
> 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.
Now I get your idea better...
Instead of
method(unresolvedparam){
resolved = getService().resolve(unresolvedparam)
use(resolved);
}
I should do
method(resolved ){
use(resolved);
}
:-D
>>How can I make these components serviceable?
>
> Do not make services out of objects.
IE, objects shouldn't use services at all.
>>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.
:-D
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
