Jeremias Maerki wrote:

> > 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).
> It's an API. You don't necessarily see implementing classes in the
> specification. Compare to JAXP. Theoretically, RenderX could implement
> the same API and we would have a common API for XSL-FO processing. It
> would even be interesting to do an implementation of that API based on
> the maintenance branch. It would probably not support all the features
> but JAXP implementations also don't do that always.

Well, its a whole lot more than an API and there are some implementing
classes in your spec. However, thanks for clarifying.

> > 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.
> It's not an Avalon-specific reason why I specified the factory. For one,
> it's almost the same as in JAXP (The whole API is, BTW). The distinction
> between FOProcessorFactory and FOProcessor is the following:
> FOProcessorFactory has a configuration (where do the fonts come from,
> what's the caching strategy etc.etc.). You will want to have one such
> object per environment where FOP is used.
> FOProcessor could be argued to be superfluous if it weren't for the
> add/removeEventListener methods which allow you to register a listener
> to get events on a particular processing run (start page-sequence, new
> page, content clipped, end page-sequence, this kind of things). I
> haven't come up with more, yet, but I can imagine that this class could
> get additional methods later.
> Basically you distiguish the basic environment from the processor run.
> You wouldn't want to reload all the configuration stuff each time you
> want to run FOP.

OK, so FOProcessorFactory is roughly equivalent to Session and FOProcessor
is roughly equivalent to Document (I don't care about the terminology, I'm
just trying to find where we thinking the same and where we are not).

> > 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.
> From the first discussion we had I got the impression that it's not
> worth the pains right now. In the worst case you simply hold the stuff
> from RenderContext in the ProcessorContext.

OK. Since it doesn't affect the API, we can always add it back later if

> > 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
> > unravel.
> >
> > 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.
> Of course, it can be reused. Nothing prevents you from passing in the
> same DocumentMetadata into the FOPResult. But nobody will want to do
> that anyway because metadata like "title" will probably change with each
> document being processed. I think we don't talk about the same thing.

That is not reuse. The metadata example is a trivial one. A Collection of
Fonts used and Fonts to be embedded would be a more important one. However,
I don't care. You are correct that we aren't talking about the same thing.

> As I said before, what I'm trying to do is separate the inner workings
> from the API as well as possible. Things from FOPResult (including the
> metadata) will probably be placed in the RenderContext so you'll have
> access to it if necessary. I see DocumentMetadata only as a pass-through
> thing to the Renderer.
> > > - 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.
> Right. but I think RenderType is not the right name for this because it
> only suggests to be information about which renderer is to be used. It
> omits all the nice parameters you want to pass over.

I don't understand your last statement, but I agree that FOPResult is a
better name than RenderType.

> > > 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).
> As I said, it's the same as JAXP. I don't see why people will have
> problem with that. It's a clean separation into input, output, setup and
> hook into the processing run.


> > 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).
> The only thing I would reuse in my API is the factory instance because
> this is the place where the Avalon Container would sit and which would
> manage all the inner services. The image cache service for example.
> Per-processing-run caching would be hooked into the ProcessorContext.
> It's the FOProcessorFactory implementation that will be heavy-weight,
> the rest is all light-weight.

Hmmm. The whole thing seems pretty heavyweight to me (at least compared to
my proposal). Since my real interest is Control and not API, I think the
most productive thing for me to do is to simply defer on the API issues to
those of you who care more about them. As long as we can build whatever
Control infrastructure under that API that we want to (and it looks like we
can), and if you guys are happy with the API, we can defer that part of the
discussion until another day. It may very well be that when I see how your
vision is implemented, I will find the Control structures that (I think) I
need and that we are done anyway.

Victor Mote

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

Reply via email to