> -----Original Message-----
> From: Joerg Pietschmann [mailto:[EMAIL PROTECTED]]
> Sent: August 13, 2002 4:53 AM
> To: FOP Dev
> Subject: Re: just a thought
> Oleg Tkachenko wrote
[ Snipped Oleg's proposal ]
> I thought I posted this two weeks ago. I made some
> measurements with the FOP examples and a few other
> FO files an get roughly the following statistics:
> 45% no child (mostly text nodes, but also fo:page-number and fo:region-*)
> 40% one child (many blocks and basically all inline FOs in the examples)
> 10% 2-5 children
> >4%  6-9 children
> <1% more than 9 children.

Hmmm, maybe your subject line was ambiguous or confusing? Looks like we all
missed that. :-)

I overlooked the "PCDATA as child" case...taking that into account there is
no doubt that 1 child is an important case. But I am still not convinced
this case needs treatment different from the "2 or more children" case as
Oleg proposed.

> The FOText text node is the only subclass of FONode which
> is not a FObj. I considered moving the children vector to
> FObj and had it almost ready to commit but failed on a
> few issues which I think I have a solution now so that I
> can tackle this (in the maintenance branch) again.
> Constructing the children vector lazily is of course part
> of this. It is, however much more than just a null test in
> addChild(), because many FO classes access the children vector
> directly, every access has to be protected with a check for
> a null vector as well.

Right, it is both adding and retrieving that needs checking. However, in the
adding case it is the callee that is responsible for checking; in the other
case it's the caller that needs to look at what it got back.

> Another thought in this regard: I was tempted to create
> an abstract FObjComposite which is the only one which can
> have children in the generic sense, and have FOs like
> fo:layout-master-set, fo:table and fo:page-number-citation
> no  generic children at all (only typed children like
> fo:simple-page-master, fo:table-body etc. which are stored
> separately anyway, mostly in properly typed fields). The
> problem here is that this could interfere badly with
> extensibility. OTOH, what should be extension elements which
> are children of fo:layout-master-set, fo:table and
> fo:page-number-citation good for? I asked this already,
> without any response.

I think this is a useful alternative. Using the DOM as an analogy, where we
have either the Node-based view or the typed view (Elements, Attributes,
Text, etc), the FO operations in Fop could be all quite generic (addChild(),
getChildren(), hasChildren(), etc) or more targeted (addText(), addInline(),
addBlock(), addSimplePageMaster() etc), or hybrid, as suggested above.

I am partial to the use of typed children, including marker children. I am
not a big fan of the generic approach, not any more (if I ever was). I don't
think a typed child approach would interfere with extensibility, and I think
the primary advantage is that the code is more self-documenting. Accessor
methods could also be more specialized. Also, the sophisticated
content-model checking that one needs to do with XSL is easier done, the
sooner you move to explicit knowledge of what you are adding to what.


To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to