--- 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

Reply via email to