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.
- 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).
- 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.

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.

Side note WRT resolvers: I've only placed the SourceResolver in the API
because I think that the other resolvers are not necessary. I'm not
certain about that but this can be easily added later.

On 20.06.2003 21:40:09 Jeremias Maerki wrote:
> On 20.06.2003 21:34:28 J.Pietschmann wrote:
> > Could you outline your API ideas on the Wiki?
> Yes, please. I'm also in the process of writing down my ideas. That way
> it will be much easier to relate everyone's ideas to each other. At the
> moment I wish we could all sit together and figure it out by talking
> together and painting on a whiteboard. The Wiki will have to suffice I
> guess.

Jeremias Maerki

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

Reply via email to