Jeremias Maerki wrote: > Hi Vincent, > > well, the "print" renderer doesn't really have an official MIME type. > The result could be paper, PDF, PostScript or whatever. I've given it a > pseudo MIME type "application/X-fop-print" just so configuration works > for this renderer, too. So it really depends how you look at it. > > But I've just noticed that there's another renderer that really doesn't > have a MIME type: Java2DRenderer. So, if anyone subclassed > Java2DRenderer to paint pages in their own Swing application they are > going to find themselves with a compile error next time they upgrade. > Actually a reason to put the getMimeType() back in AbstractRenderer. > However, they have to implement getMimeType() anyway if they want to > configure the renderer through the XML configuration so probably no harm > done.
Ok, so the mime type is essentially used for configuration purpose, in which case leaving it to null simply means that the renderer does not need that feature. It makes sense then to have a default implementation in AbstractRenderer. OTOH, not defining one forces to think about that when implementing a renderer. Maybe safer. Thanks for the explanations, Vincent > On 03.04.2009 12:31:32 Vincent Hennebert wrote: >> Hi Jeremias, >> >> Jeremias Maerki wrote: >>> Hi Vincent, >>> >>> Removing getMimeType() on AbstractRenderer is ok although that could >>> break someone else's renderer (risk very slim). But I'd rather move the >>> getMimeType() implementation from PrintRenderer to PageableRenderer. >>> That alone doesn't solve Rey's problem but get one step closer. I'll do >>> that if you don't mind. >> Sounds good, thanks. >> BTW, I’ve just noticed that the javadoc of Renderer.getMimeType() >> explicitly states that the returned value may be null. >> Does it still apply today? Can we reasonably expect a renderer not to >> return any mime type? >> >> Vincent >> >> >>> On 03.04.2009 11:40:20 Vincent Hennebert wrote: >>>> Hi, >>>> >>>>> Author: jeremias >>>>> Date: Fri Apr 3 07:44:09 2009 >>>>> New Revision: 761554 >>>>> >>>>> URL: http://svn.apache.org/viewvc?rev=761554&view=rev >>>>> Log: >>>>> Fixed a bug that left the PrintRenderer unconfigured even if a >>>>> configuration was specified for "application/X-fop-print". >>>>> >>>> <snip/> >>>>> + /** {...@inheritdoc} */ >>>>> + public String getMimeType() { >>>>> + return MimeConstants.MIME_FOP_PRINT; >>>>> + } >>>>> + >>>> This method is defined in AbstractRenderer to return null. That makes me >>>> wonder: is there a use case where you can expect a renderer to return >>>> a null mime type? >>>> The answer probably is no, in which case the definition of this method >>>> should be removed from AbstractRenderer. That would force concrete >>>> classes to implement a sensible getMimeType method and prevent this kind >>>> of bug from occurring. >>>> If I do it, the only class that no longer compiles is PageableRenderer. >>>> Given that it is sub-classed by PrintRenderer and its constructor is not >>>> called by external classes, I guess it can be made abstract. >>>> >>>> Is that ok if I apply such changes? >>>> Thanks, >>>> Vincent >>> >>> >>> >>> Jeremias Maerki > > > > > Jeremias Maerki >
