On 07.01.2005 11:01:28 Glen Mazza wrote:
> --- Jeremias Maerki <[EMAIL PROTECTED]> wrote:
> 
> > You're right, my change was suboptimal. When I think
> > about this I must
> > say that I'd prefer to remove that check entirely
> > and let the individual
> > renderers check if they have everything to write to
> > their target. 
> 
> I don't think so, because we need early checking at
> the command line and embedded usage to make sure all
> input is OK before proceeding.  That's a very common
> paradigm used in just every compiler or text
> processor.  FOP has been doing this for several years.

I think you're confusing things. Checking for the availability of an
OutputStream has absolutely nothing to do with the command line. Command
line parameter validation is the responsibility of the
CommandLineOptions class. If through the command line no OutputStream is
set it's a bug in FOP. If someone embeds FOP in his/her application the
not supplying an OutputStream when a renderer needs one is a bug and so
it doesn't matter if the error message comes early or only when the
renderer is started (Renderer.startRenderer()).

> > The
> > renderer knows best what it needs. 
> 
> I don't think so--all of the non-AWT based renderers,
> for the past seven years, require a OutputSource and
> only an OutputSource.  We never had a user complaint
> on that or a request otherwise for a change.  It has
> never been a problem.

You mean OutputStream, not OutputSource, don't you?

> BTW, you are glossing over how one can generate a PDF
> or any other output document without using an
> OutputSource.  Absent user demand or a technical
> explanation from you on this point, I can't really
> support your position.

Ok, here's your technical justification:
I'm certain you've seen the new test subsystem for the layout engine
where I analyze the output of the area tree renderer. If I wrote the
area tree to an OutputStream I'd have to parse it again later, so I get
a DOM I can evaluate XPath statements on. If I can pass in a
TransformerHandler into the XMLRenderer the renderer can simply send SAX
events which are used by a Transformer to build a DOM from (directly).

Ok, this is no end-user use case but it's still a use case. You could
even argue that speed is no big issue in this case. Granted.

So here's another one. Do you know about SVG Print? An SVG renderer
could send the generated SVG using SAX. That way a developer could run
the generated SVG through an XSLT post-processing without having to
reparse the generated SVG. That's a place where speed is very important
and an OutputStream-only system would be suboptimal.

> > Having this check
> > in the
> > RendererFactory only puts renderer-dependant logic
> > in a place that is
> > renderer-agnostic. If it's ok by you I'm going to
> > fix that.
> > 
> 
> Personally, I would rather we get rid of
> RendererFactory and put the logic back where it
> was--in FOTreeBuilder and RenderPagesModel.  This
> functionality is just too specific to be reused
> elsewhere in FOP.

I don't see your point and you were the only one who complained about
the RendererFactory. I still think the RendererFactory is A Good Thing 
(tm). It reduces imports, dependencies and number of lines in
FOTreeBuilder and RenderPagesModel and centralizes instantiation of the
Renderers and FOEventHandler in one place where they are easier to find
for those unfamiliar with FOP sources.

I'll gladly submit to a veto against the RendererFactory if it is
supported by at least another committer.

> > I see two possibilities: Adding a RENDER_CUSTOM
> > constant or having a Fop
> > contructor without this constant.
> > 
> 
> RENDER_CUSTOM is OK.  (But there can also be
> advantages of still encouraging users to use
> RENDER_PDF, for example, if the override is still a
> PDF renderer.  e.g., checking for an output source or
> other business logic.)

Ok.

> > Please keep in mind that if you simply define a new
> > API, release and
> > then change according to user feedback you can't
> > just change the API in
> > an incompatible way again. You'd have to provide
> > API-compatibility
> > within smaller version steppings. See for example
> > [1].
> > 
> 
> Indeed, this reason is why I'm against adding API
> methods without an explanation of the technical needs
> for them, or bothering to point to user demand or
> requests for them first.  Once it's there, we're
> forever stuck with it unless we do another major
> release.  So I think you should be keeping versioning
> etc. in mind as well.
> 
> This is also the reason why we are using a simple
> JAXP-based API--something we know that we will support
> now and forever.  (Adding to an API is always OK, as
> more functionality and enhancements are provided--it
> is *subtracting* from it that causes the problem.) 
> Additional functionality should be based on user
> requests and needs, not every possible theoretical
> usage.



Jeremias Maerki

Reply via email to