> -----Original Message----- > From: Glen Mazza [mailto:[EMAIL PROTECTED] > <snip /> > But the nice thing about our system is that they don't > have to follow AbstractRenderer. AR implements an > interface called Renderer, which is the bare minimum > of methods needed to implement a FOP-compatible > renderer. Since InlineAreas never call > renderInlineXXX anymore, I pulled it out of the > Renderer interface. Now, a renderer can create > methods of its choosing for implementing inline area > rendering--so a Renderer implementor now has more > design options. >
You've convinced me fully. Thanks for the enlightenment. <snip /> > > > In order to be able to respond to such a call, the > > InlineArea inevitably > > gets coupled to the different possible renderers > > Actually no--The Renderers get coupled to the > InlineArea, as well as every other type of Area > object, which is fine. Working with InlineAreas, > querying their traits, rendering them, etc., is their > job. But the InlineAreas aren't coupled to the > Renderers anymore--they don't make a reference anymore > to Render objects in their code. > > InlineArea ia.getTrait(); within the renderer code for > example: Renderer knows about IA but IA is now > oblivious that it's being used by a Renderer object. > Aah! So the references were more like 'remnants' of the previous design, then? (Apart from that, I was paying too little attention to the distinction between Renderer<->AbstractRenderer...) Nice cleanup IAC. Cheers, Andreas
