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.

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

Reply via email to