> -----Original Message-----
> From: Glen Mazza [mailto:[EMAIL PROTECTED]

Taking your pros into account:

on 1.) +1

Now that you mention it, I have a vague suspicion that this is somehow
related to the bug WRT basic-links I pointed out earlier (for which I was
going to send some test file, but I'll put this off for now, and see whether
the change solves this, and if so, what part is solved. If we decide to go
back at some later point, we might then be able to prevent it from happening

on 2.) +0

I see myself as unable to judge whether 2) would be good or bad, but I'm
inclined to believe the latter (see below). However, FOP is an integrated
product, for which one would ideally have to be able to write new renderers
without too much hassle. If you think your proposal would encourage this, I
see no reason for a -1.

In your reply to Joerg's objection, your arguments would certainly make
sense in certain circumstances, only the analogy being drawn concerns me a

<snip />
> This is not a very good OO design in three ways (comparing
> buyWhatGlenWants(this) vs. getCapital()):
> 1.)  The private functions buyXXXX in class Glen now have to be made
> public.   (Likewise, in AbstractRenderer, all of the renderInlineXXXX
> need to move from protected to public to allow for such external calls
> from the InlineAreas.)  (This doesn't occur with getCapital().)

Does any package other than the renderers really *need* access to the
renderInlineXXX methods? It seems to depend on whether one wants to be able
to have:

a) an InlineArea that 'knows how to render itself'
b) an InlineArea that 'knows how to provide data about itself to the
renderer when asked for it'

The logic is not meant to be 'the AbstractRenderer asks the InlineArea to
render itself', but rather, 'the AbstractRenderer asks the InlineArea for
the specs necessary to render it'.
In order to be able to respond to such a call, the InlineArea inevitably
gets coupled to the different possible renderers --and the degree of
complexity of this coupling is solely determined by the extent up to which
the different renderers share a common interface.

> 2.)  The Country classes get coupled with objects not relevant for them
> (here, class Glen), and hence become less pluggable.  (Again, this
> doesn't occur with getCapital().)  In our code, the InlineArea
> subclasses end up being unnecessarily tied to the renderers.

See above: I think 'unnecessarily' should be 'inevitably'. I agree 100% on
the point of keeping the tie transparent/as simple as possible, but the fact
of being tied itself obviously cannot be avoided.
It would make the AbstractRenderer... too abstract IMHO. If the InlineArea
knows what to do to render itself, you wouldn't need all the different
renderers, would you? --or at least, you wouldn't really need an 'abstract'
renderer if the areas are going to be talking the 'concrete' renderers

> 3.)  The business logic for what Glen wants to buy while in Canada is
> being maintained in the wrong class.  Should Glen choose to buy
> something else in Canada, class Canada needs updating.  (On the

What about the consideration that class Canada provides for a
getAvailableProducts(), or what if 'buying' means something else in the US
than it does in Canada?

OK, bad example maybe, --try 'buying in the US vs. buying in India', might
get us closer
--but anyway, whether your given example proves your point rests upon these
suppositions (amongst others):

- Glen knows what buying means in all possible countries
- Glen knows what products are available in all possible countries, or
expects that all products he needs are available in all countries he is
going to buy from/in

Would these hold for the relationship between AbstractRenderer<->InlineArea?

The 'more correct' design, I believe, would be for Glen to study the Country
to find out what buying means over there, what products are available etc.,
after which he can _buy_ _something_

so a signature like

 Glen.buy( Country country, Product product, Prereqs[] prereqs )

[where prereqs refers to 'the prerequisites for buying in the country
specified in the first argument']

would be more in its place, I presume. Upon making that call, the
Country --or whatever instance is used as a salesman - can then prepare
whatever is necessary to complete the transaction ( check whether the
product is available, and if so, see if Glen has taken all necessary steps
that permit him to buy the product he wants...)

> > [Joerg: ]
> >
> > But this is what keeps the renderers pluggable. If these
> > methods are removed, every renderer must follow the same
> > design.
> I don't understand this point completely (using the country example
> above, everyone would need to buy hockey skates, but by moving the logic
> down to the person, class Joerg can buy something else.)  But at any

You don't have to move the logic down to the person in order to let them buy
something else (and perhaps it is even better not to do so).
I think the point is that it's not 'everyone *would need* to buy hockey
skates in that country', but 'everyone who wants to, *could* by hockey
skates there, and to do so, they *would need* to follow a certain logic'.

So, pluggable renderers, maybe in the sense of 'having a set of predefined
methods to which eventual renderers must provide an implementation in order
to render FOP's InlineAreas'... ?

Wasn't one of the reasons for the redesign that one could add new features
to different parts of the process without having to resort to 'ugly' hacks
(--thereby creating a codebase which FOP-veterans would gladly admit to be
rather messy in 5 years or so ;) )?

Just a thought..



Reply via email to