[Glen]
Extension elements are handled within
validateChildNode() just like regular formatting
objects, such as e.g. fox:bookmarks in fo:root [2].
We appear to have two categories of extension elements:
1.) (svg and MathML for example): These are dynamically loadable extension elements that are (1) children of fo-instream-foreign-object and (2) don't affect layout, renderers, the area tree, etc.
Ok.
2.) (fox:bookmarks, fox:outline, etc.) These are
non-runtime-loadable extension elements that work
directly with formatting objects and whose output must
be coded within FOP proper. (fox:bookmarks, for
example, include logic in area.AreaTreeHandler,
PDFRenderer perhaps, and additional code in the PDF
library.) Adding these elements requires not just
adding an extension element class but additional code
in layout/renderers/area objects, etc.
You are IMHO overly focused on the dependencies.
Please note that I have two different roles: FOP developer and extension writer. As an extension writer, I can't modify the FOP sources at all.
Extension writers has to create a subclass of AbstractLayoutManager (I just use a LeafNodeLayoutManager) and an subclass of Area. But that are normal operations since there are subclasses of those for each element type. I must also add code to the renderer to handle my area, but that is because the renderer code is not flexable enough to handle unknown area classes. I get around that limitation by plugging in a completely new PDF renderer.
For these extension elements, they have to be validated just like the XSL FO's do: you have to determine which nodes can have these extension elements as children, their location, cardinality, etc., etc. So for these elements, you will probably need to subclass/rewrite the vCNs() of parents which may have them.
Having to subclass the parents will prevent two different unrelated extension from both having fo:block's as parents. Also, I can't replace the Block class with my subclass in the FOElementMapping without changing FOP sources.
(Of course, once the element is directly incorporated into FOP, subclassing will no longer be needed.)
The main extension I have in mind can never be incorporated in FOP due to licensing.
But this shouldn't be a problem, because you have to
modify the renderers, layout, and/or area objects
source code anyway for the extension element to work.
It has worked quite well before. Without changing any of FOPs layout or area sources.
It's not like you are losing dynamic run-time
loadability here,
Oh, yes I am.
and generally a vCN() does not add much more to the work you have to do. (Actually, vCN() tends to reduce coding complexity of work downstream.)
I would have to subclass Block and replace the mapping of <fo:block> to my subclass. I didn't have to do any of this before. And I can't do that as an extension writer.
My guess is that the
validation should only occur when one fo namespace element is added to
another fo element.
I don't think you mean that completely--that's too loose. We should be leery of a system that would allow, say, svg:rect to be a child of fo:block. FOP just wouldn't be solid that way, and who would want to maintain the Bugzilla list that would result from that? ;)
I mean exactly that the validation should be loose. If I need a <finnbock:foobar> tag as a child of fo:block, fo:block should not prevent me from doing so. I promise that I will not post the resulting bugs to Bugzilla.
Perhaps the extension elements can implement a tag interface to indicate that the extension shouldn't be validated by the parent. Or parhaps the checking could be disabled entirely.
The benefits of vCN() is to (1) stop problems at the
source, prior to creating the node, rather than risk
many Bugzilla and FOP-User ML messages of subtle
NPE/CCE problems that would otherwise occur
downstream, and (2) reduce the amount of sometimes
duplicative error checking distracting the business
logic downstream, and (3) provide a uniform
error-messaging system.
All true, but to an extension writer it doesn't really matter.
For instance, Block.validateChildNode() doesn't
allow any of my extension elements as children.
Yes, you will need to modify it for your new element. But first you have to (1) define which parents your
element is good for, and (2) where they need to be
located among those parent's children. The fact that
vCN() forces one to stop first and define these things
is IMO actually a Good Thing, and would have to be
done anyway should the element be eventually
incorporated into FOP.
(BTW, for extension elements that are valid in multiple places, take a look at our isBlockItem(), isInlineItem() and isNeutralItem() in [3]--you may be able to just place your extension elements there if they are valid in the same places that the elements defined there are.)
regards, finn
