Jeremias Maerki wrote:

> I have done so now. I've added a new (sub)page to the Wiki to avoid
> making the FOPAvalonization page even longer.
> While writing down my thought about the API I have come to the
> realization that I cannot make up my mind about the inner context
> classes Victor has come up with. But I think he's quite close:
> - Session: Looks like my and Jörg's FOProcessor to me. The user
>   interacts with this class to configure FOP and do processing runs.

I think your name is fine. I am confused about whether it is an interface
(as written) or a class (I don't see any implementations). I guess I don't
understand the need for FOProcessorFactory, which seems to be an unnecessary
complication for the user. Since I don't understand Avalon, I am not sure
how factoring it into/out of this affects the API, but if that is needed, it
seems like it should be done in an implementation of FOProcessor instead of
creating separate Factories.

> - Document and RenderContext: I'm not sure but I think these two should
>   be merged. I've called it ProcessorContext in my proposal at first,
>   but then chose not to include them in the proposal right now because
>   I didn't quite know what to put in there. The thing I know is that we
>   need a central data object that keeps references while the FOProcessor
>   implementation coordinates the processing (data separated from logic).

RenderContext is only useful if you are trying to reuse an AreaTree for
multiple output options. I am frankly confused right now about whether the
dev team even wants to try to do that. I think it is a good idea, and
suspect that whatever difficulties have existed in implementing this in the
past are probably a result of our current tight coupling between FOTree,
layout, AreaTree, and Rendering, which is of course what I am trying to

Your DocumentMetadata class holds information in it that would live in my
Document concept. That is information that is common to (but not necessarily
used by) by all output media, and does not need to be set for each output
media. It looks like you are pushing the data that I envisioned in Document
and RenderContext down to RenderType/FOPResult. The net effect is that it
can't be reused.

> - Renderer: You guys hate me for that, I know, but I still refuse to
>   give it so much visibility in these discussions. In my proposal I've
>   separated the logic from the data again (with JAXP as role-model) and
>   made the Renderer a totally normal Avalon service that is being looked
>   up by MIME type in the background. The FOPResult classes account for
>   the differences of output types. The FOProcessor impl is responsible
>   to establish the link between FOPResults and Renderer. For AWT (I'd
>   like to call it Java2D from now on if you guys agree. That's the
>   official name of the API after all.) I've tried to introduce an
>   interface that clients can use to interact with the Java2D renderer.

Your FOPResult is I think roughly equivalent to what I am calling RenderType
or Renderer (somewhere along the way, I started calling mine RenderType to
make a more clear distinction between it and the workhorse Renderers), and
if I understand what you are doing, I think our goals are the same.
FOPResult is more of a control class, and the Renderer is a workhorse class.

> So, I don't have anything more concrete on the inner "glue" that keeps
> the whole process together but maybe my proposal brings some new ideas.
> I'd like to hear your thoughts about my proposal (flaws, nodding,
> missing things etc.).
> I hope that we can find a common path for the whole thing. Important to
> me is to have a good terminology and an API that conforms to the
> requirements I've written down on the FOPAvalonization page.

Here are the issues that I am still uncomfortable with:
1. complexity. In addition to the Factory issue already mentioned, I think
there is some benefit to arranging the data more intuitively for the user.
>From the user's standpoint, there is input and output (ie. 2 classes). It
makes sense to have a third (Session/FOProcessor) primarily to facilitate
reuse. IMO, if the user has to interact with more than 3 classes to get the
work done, we are unnecessarily complex. (My 4th class, RenderContext, is
not exposed to the user).
2. reuse. I see no downside to arranging our objects to allow reuse, even if
we decide we don't want to facilitate it. This doesn't directly affect the
API (we can have 15 or 50 classes supporting those exposed to the user).

Sorry to be so slow responding.

Victor Mote

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to