xmlgraphics-fop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremias Maerki <dev.jerem...@greenmail.ch>
Subject Re: cvs commit: xml-fop/src/java/org/apache/fop/apps FOUserAgent.java
Date Mon, 11 Oct 2004 20:24:24 GMT
Glen,

I don't want a RendererFactory.setRendererOverride(). I don't
particularly like selecting renderers by integer constant. I like
pluggability. I'd prefer to register all our renderers in a central
registry. Integrators could plug in their renderers using the service
interface just as the FOP extension can. You could even override
renderers (for "application/postscript" for example) if you have a
renderer with some custom extensions. IMO FOUserAgent is already
overloaded with too many different things. I think that the overrides
don't belong there, or rather they are probably unnecessary given a
better renderer selection mechanism.

What triggered the creation of the RendererFactory was not IoC but the
other Avalon concept: Separation of concerns. I think that handling
renderer and FOEventHandler creation in a separate class rather than in
the quite crowded FOTreeBuilder and RenderPagesModel improves code
readability.

Don't get me wrong. I can live with the current situation as long as I
can plug in my custom FOEventHandler. You don't object to that, do you?
The RendererFactory simply came out of the fact that I need to plug in
my FOEventHandler and I found that the code was IMHO a bit unclean.

By the way, my change didn't change the end-user API, so I don't see any
reason why RendererFactory is a bad idea. Do I miss your point?

On 11.10.2004 01:46:54 Glen Mazza wrote:
> Jeremias,
> 
> The reason for getFOEventHandlerOverride()/getRendererOverride() in 
> FOUserAgent is to better black box the FOP system.  This gives us a ton 
> of freedom internally of where we implement FOEventHandlers and 
> Renderers inside FOP.  This has been a perfect example:  So far over the 
> past few months, we've been setting the renderer in apps.Driver(), then 
> in fo.FOTreeControl, then in area.AreaTreeHandler, and then in 
> RenderPagesModel, and now RendererFactory.  But note that during all 
> these movements, FOUserAgent.getRendererOverride() never had to change!  
> I don't know if this is what is meant by Avalon's Inversion of Control, 
> or if this is a separate concept, but it is providing us wonderful 
> flexibility.
> 
> If, instead,  we provided a user interface that had the outside user 
> *directly* call RendererFactory.setRendererOverride(), we would be 
> forever stuck with having this code in a RendererFactory class.  Good 
> for you, but some preferred it in AreaTreeModel, and some wanted it in 
> apps.Document or apps.Driver.  Point is, future committers, because of 
> backwards compatibility issues, would be forever frozen with a single 
> design.


Jeremias Maerki


Mime
View raw message