On Aug 24, 2005, at 22:46, Peter Herweg wrote:
Hi Peter,
The tables don't work because I iterate recursivly through the FO and
its
child-nodes. But the TableColumn objects are not added to ChildNodes
of the
Table object. Instead they are added to a separate Array, so do also
TableFooter and TableHeader (refer to Table.addChildNode). Of course i
can
consider this when I iterate the FO and additionaly iterate these
arrays.
But I'am afraid this will end up with a lot of "if"s and "else if"'s in
order to process all necesarry FOs.
Well, concerning the increase in conditional branches, I must say I
feel more or less the same way about them, but still IMO, in most
situations that's more a matter of aesthetics than of efficiency. A
carefully chosen set of tests put in the right order doesn't have to
cost that much in terms of performance/resources.
I guess that what I mean is: I wouldn't worry *too* much about that
type of issues ATM. If you can make it work *with* a lot of conditional
branches, then by all means, go for it.
Afterwards we can still start thinking about ways to cut those down to
a minimum.
I explicitly say 'we' because, however badly you may feel about the
looks of the code, once it's in the repository, more eyes can look at
it, so you have an increased probability of *someone* coming up with
ideas on how to improve it. If there is nothing, any potential
developer would have to start from scratch, which is even less
desirable than a few if-else-if's too many.
In this case, if the increased number of conditional branches results
in increased functionality, I think that would be well worth the trade.
One simply CANNOT expect to be able to extend functionality without
having to pay a price for it somewhere...
Cheers,
Andreas
