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
