> -----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.



Reply via email to