Re: svn commit: r761554 - in /xmlgraphics/fop/trunk: src/java/org/apache/fop/render/print/PrintRenderer.java status.xml
Hi,
Author: jeremias
Date: Fri Apr 3 07:44:09 2009
New Revision: 761554
URL: http://svn.apache.org/viewvc?rev=761554view=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
Re: svn commit: r761554 - in /xmlgraphics/fop/trunk: src/java/org/apache/fop/render/print/PrintRenderer.java status.xml
Your suggestion sounds sensible enough to me (without having found time
to take a look at the code), +1.
Adrian.
Vincent Hennebert wrote:
Hi,
Author: jeremias
Date: Fri Apr 3 07:44:09 2009
New Revision: 761554
URL: http://svn.apache.org/viewvc?rev=761554view=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
Re: svn commit: r761554 - in /xmlgraphics/fop/trunk: src/java/org/apache/fop/render/print/PrintRenderer.java status.xml
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=761554view=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
Re: svn commit: r761554 - in /xmlgraphics/fop/trunk: src/java/org/apache/fop/render/print/PrintRenderer.java status.xml
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=761554view=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
Re: svn commit: r761554 - in /xmlgraphics/fop/trunk: src/java/org/apache/fop/render/print/PrintRenderer.java status.xml
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.
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=761554view=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
