--- Finn Bock <[EMAIL PROTECTED]> wrote: > > Option #1: > > > > 1.) myextension.jar will need a FOElementMapping > [1] > > subclass that will reroute fo:Block from > Block.java to > > FinnBlock.java. Have FinnBlock.java override the > > vCN() for the new validation rules. > > This would eventually cause a conflict with the > GlenBlock.java from an > extension written by you. >
I don't think so, because there is only one XSL fo:block element, which must have one and only one content model. If I want to incorporate extension elements from multiple extension jars, I'll need to code so accordingly in my own GlenBlock.java, which would incorporate, say, extensions from FinnExtension.java and extensions from SimonExtension.java, and define the ordering and cardinality of the them. Next, I'd have to create a GlenBlockLayoutManager that will take care of all of these different children from different extension elements. The children of an fo:block object are just not dynamically additive: they are precisely ordered with cardinality. For fo:root, for example, the order must be fo:layout-master-set, fo:declarations?, fo:page-sequence+, *in that order*. Content models, derived from DTD models, do not allow for random ordering of child elements. Note this stuff needs to be rendered in layout eventually anyway, so even if you can dynamically discover the children of an FO -- and come up with an algorithm to order them -- you will need to create a LayoutManager would need to be able to dynamically handle them as well--eventually these extensions elements would be conflicting with each other otherwise. Glen
