xmlgraphics-fop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Finn Bock <bck...@worldonline.dk>
Subject Re: validateChildNode prevents extensions.
Date Sat, 28 Aug 2004 13:25:10 GMT

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


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


View raw message