--- 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. > 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. 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. > 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 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.) > 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. Thanks, Glen
