Hello Finn, [BTW, before I get to this topic, as you've probably noticed by now I've finished removing the AddLMVisitor. In the process, I also created about eight new layout manager classes, pulling out the layout business logic that used to be in AddLMVisitor. As a result, the maker system you were suggesting should be MUCH smaller to implement now--probably can be kept in one class similar to [1]. Would you agree? If so, if you still like your suggestion--I don't care either way--feel free to add such a maker system in anytime--Simon also was preferring your design.]
--- Finn Bock <[EMAIL PROTECTED]> wrote: > Glen > > I think that the new validateChildNode() methods are > too strict in > response to extension elements. 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. (i.e., *no* change to FOP source code is needed in order for these elements to work.) FOP, in fo.FOTreeBuilder, already has a couple of hooks for run-time discovery and loading of such extension elements. For these types of extension elements, validateChildNode() doesn't hurt anything. The vCN() in fo-instream-foreign object just enforces, per the spec, that there is only one child, and that it is in a non-XSL namespace. 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. 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. (Of course, once the element is directly incorporated into FOP, subclassing will no longer be needed.) 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's not like you are losing dynamic run-time loadability here, 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.) > 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? ;) 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. > 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.) Sorry for the long post. Glen [1] http://cvs.apache.org/viewcvs.cgi/xml-fop/src/java/org/apache/fop/fo/FOElementMapping.java?rev=1.8&view=auto [2] http://cvs.apache.org/viewcvs.cgi/xml-fop/src/java/org/apache/fop/fo/pagination/Root.java?annotate=1.23#100 [3] http://cvs.apache.org/viewcvs.cgi/xml-fop/src/java/org/apache/fop/fo/FObj.java?annotate=1.69#462