Sorry for the delay.
On 12.10.2004 01:20:54 Glen Mazza wrote:
> --- Jeremias Maerki <[EMAIL PROTECTED]> wrote:
>
> > Glen,
> >
> > I don't
> > particularly like selecting renderers by integer
> > constant.
>
> FOP has been using integers for six years now, and as
> I explained earlier [1], MIME types don't make a very
> good primary key for renderers, because not all
> renderers have a MIME type, also multiple renderers
> can share the same MIME type (e.g. our PDF renderer
> and Finn's version of it.). In some cases, we would
> may indeed need a RENDER_PDF_V14 and an
> RENDER_PDF_V15, for example.
I would disagree with that. There are ways to do all that pretty cleanly.
The point is that with your approach you always (!) have to work in Java
code to use a non-standard renderer. It can't be plugged in from the
command-line for example.
> Again, integer constants also work well in arrays,
> they are ultra-fast, and, as a bonus, "new
> Fop(RENDER_PFD)" is a ultra-quick-to-catch
> compile-time error, while new FOP("application/pfd")
> would turn into a pesky run-time error (and even a ML
> question). The integer constants are also much easier
> to remember than MIME types: RENDER_ followed by the
> desired render type.
Performance is really unimportant when we're talking about choosing the
renderer. The compile-time checking argument is valid, however.
> [1]
> http://marc.theaimsgroup.com/?l=fop-dev&m=109261374110951&w=2
>
> > I like
> > pluggability.
>
> We sufficiently have that for our next release, where
> I define "sufficiently" as "as much as we have already
> in 0.20.5, and basically what AH/RX offers". We have
> already learned that adding too many hooks,
> interfaces, visitor patterns, *before* the
> layout/renderer work is done, results in FOP never
> getting finished because the code becomes too hard to
> work through. So let's get the code working first
> (moving the renderers over, whitespace handling, PDF
> bookmarks, layout), *then* put it into Mandarin with
> the advanced API many desire.
As you like. But this will stay on my personal todo list.
> I share your impatience with the next release not
> coming out yet, but we have to keep the code simple to
> get more people to look at and help in the code.
I agree, but IMHO it's confusing that we're choosing standard renderers
in one place (Fop.java) but provide a possibility to set non-standard
renderer in another (FOUserAgent.java).
> > I'd prefer to register all our
> > renderers in a central
> > registry. Integrators could plug in their renderers
> > using the service
> > interface just as the FOP extension can.
>
> That's beautiful post-0.30/1.0 talk that should be
> added to our roadmap. But, in the meantime, we
> already have a perfectly satisfactory
> FOUserAgent.setRendererOverride() that will satisfy
> the users that currently have renderer overrides. I
> would prefer a minimal API with as much black-boxed as
> possible to allow future implementors as much
> architectural freedom as possible.
>
> Besides, what you prefer now is not what the team
> preferred six months ago, or a year ago, or 18 months
> ago, etc., etc. Our API/internal architecture desires
> keep changing.
Are they? Is that how you justify ignoring API discussions held earlier?
> > You could
> > even override
> > renderers (for "application/postscript" for example)
>
> We already have that with
> setRendererOverride(Renderer). You can't use MIME
> type for reasons given above.
I can't override a Renderer without changing Java code.
> > if you have a
> > renderer with some custom extensions. IMO
> > FOUserAgent is already
> > overloaded with too many different things.
>
> That is because we tend to, whenever any user might
> want something, give him/her an API method for it.
> The only way we can satisfy these many needs without
> forever locking the FOP architecture (each of these
> switches internally modifying the behavior of one
> internal class or another) is to add the method to
> FOUserAgent, and have internal classes read it, rather
> than the other way around. Furthermore, we have one
> class--FOUserAgent--for these parameters to make the
> embedded/servlet API easier for non-advanced users.
> (BTW, FOUserAgent should be reduced somewhat anyway,
> when we create fox:metadata or whatever.)
Means keep Fop.java as lean as possible but no problem with FOUserAgent
getting bloated. I don't get it.
> > I think
> > that the overrides
> > don't belong there, or rather they are probably
> > unnecessary given a
> > better renderer selection mechanism.
> >
>
> Oh, I think they do, it is sufficient for our next
> release. Nothing is easier, nothing is simpler for
> embedded/servlet users. Take a look at the 1.0
> embedded examples.
My desires for the API don't complicate things for the embedded examples.
> > What triggered the creation of the RendererFactory
> > was not IoC but the
> > other Avalon concept: Separation of concerns. I
> > think that handling
> > renderer and FOEventHandler creation in a separate
> > class rather than in
> > the quite crowded FOTreeBuilder and RenderPagesModel
> > improves code
> > readability.
>
> FOTreeBuilder and RenderPagesModel IMO aren't that
> crowded, they are the size they need to be for the
> business logic they are responsible for. Still, I've
> bent over backwards to remove as many classes and
> unneeded methods to simplify the code as much as
> possible. Furthermore, bouncing around classes IMO
> raises stress rather than lowering it.
Ah, and you didn't do that lately? I believe that my change has
simplyfied FOTreeBuilder and RenderPagesModel quite a bit.
> As for Avalon SoC, the concerns *were* properly
> separated: the FOTreeBuilder chose the FOEventHandler
> based on the desired render type, and RenderPagesModel
> chooses its renderer also on the desired render type.
> It is business logic purely the departments of the
> FOTreeBuilder and RenderPagesModel.
>
> Still, I'm not objecting to this change as long as
> it's not the external API. (Indeed, I support it,
> because it makes you happy, and when you're happy
> you're more productive.)
>
> >
> > Don't get me wrong. I can live with the current
> > situation as long as I
> > can plug in my custom FOEventHandler. You don't
> > object to that, do you?
>
> Not at all, because it does not directly touch
> internal code. Future committers can move
> FOEventHandler handling anywhere they like without the
> FOUserAgent method changing.
>
>
> > By the way, my change didn't change the end-user
> > API, so I don't see any
> > reason why RendererFactory is a bad idea. Do I miss
> > your point?
> >
>
> Only if you were planning on exposing RendererFactory
> to the external API.
I don't.
> It is the fact that the end-user
> API didn't need to change for your internal change, is
> why my design of FOUserAgent is solid. (Think of a
> database view--where the view accesses several
> underlying tables. By having applications query the
> view instead of the tables, the DBA/Data Modeler is
> able to make table changes without concern about the
> application needing updating--only the view definition
> changes. This is what I would like our API to be.)
Ok, and I have a few different ideas about it.
> Future committers must have the ability to get rid of
> RendererFactory for something they deem better, just
> like you changed my design for something you thought
> was better. Our external API should mask our internal
> workings--which, along with keeping things simple, are
> my main concerns here.
And with my change I tried to make things even simpler.
Jeremias Maerki
