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. The renderer knows best what it needs. 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.
Setting the OutputStream on the Fop class is merely a convenience method that simplifies setup for normal cases. There are simply cases where no OutputStream is needed. What I don't like is using RENDER_AWT or RENDER_PRINT just to specify that I don't use an OutputStream. That's very unintuitive and misleading. I see two possibilities: Adding a RENDER_CUSTOM constant or having a Fop contructor without this constant. 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]. [1] http://jakarta.apache.org/commons/releases/versioning.html On 07.01.2005 01:19:36 Glen Mazza wrote: > Jeremias, > > Per your change here [1], no longer checking for an > OutputStream variable if the Renderer is overridden: > The render constant chosen is irrelevant when the > renderer is overridden. So the embedded programmer > can rely on RENDER_AWT or _PRINT for those > comparatively rare cases of not needing an > OutputStream (and, indeed, that would be the > appropriate render type in most of those instances > anyway.) > > People will be supplying an OutputSource for PDF-type > generation--FOP has been requiring it for six years > now with nary a complaint. If you remove that check, > and they forget to programmatically supply an output > stream (a fairly common newbie mistake), errors in FOP > will occur without informative messages. > > So I would advise the usage of RENDER_AWT/_PRINT for > non-OutputStream usage for overridden renderers, while > returning the check for the RENDER_PDF et al ones. > That should be sufficient for our next release, after > which we can then consider "what's next" based on user > feedback. > > Glen > > [1] > http://marc.theaimsgroup.com/?l=fop-cvs&m=110495921529754&w=2 Jeremias Maerki
