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 Sun, 29 Aug 2004 08:25:44 GMT

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

[Glen]

> OK, in other words, you have to change FOP source code
> to add a new XSL-based extension element.  You have no
> problem philosophically with this.

I was unclear. When I write an extension, I make *no* change to any 
existing FOP source files. And I do not replace any existing FOP class 
files with new version.

For an extension element I have to writte a new version of FO classes, a 
layout managers, an area and also a new PDF renderer but these are all 
new files with new class names.

>>Also, I can't replace 
>>the Block class with my subclass in the
>>FOElementMapping without 
>>changing FOP sources.
> 
> OK, you're saying again that you have to change the
> FOP source code in order to add a new XSL-based
> extension element, but now you're having a problem
> with adding *this* code.

I don't want to change any FOP code! And if I have to change any FOP 
sources to add an extension, then FOP doesn't support extension with the 
meaning of extension as I understand it.

> I'm still not sure why this
> is causing you so much more consternation--isn't this
> trivial (even if annoying) to what you will need to do
> in the other classes?

An extension mechanism where I can put an unmodified fop.jar and 
myextension.jar on the CLASSPATH and have it work is a defining issue to 
me. It is the mechanism that is currently paying my rent.

> Between changing code in 3 places with no validation
> for the user community (and tons of NPE/CCE complaints
> due to badly written FO's for the committers to deal
> with on the various lists), vs. changing the code in 4
> or 5 places *with* validation for the user community
> (and few if any NPE/CCE complaints), you do have a bit
> of a tough case to make that the former would win a
> cost-benefit analysis.
> 
> 
>>Having to subclass the parents will prevent two
>>different unrelated 
>>extension from both having fo:block's as parents.
> 
> 
> Not true--fo:block already allows 20 or so different
> types of children--all distinct from each other.  (But
> to further simplify your coding, all you have to do is
> check that the namespace URI is "www.finn.com" or
> whatever and you can choose to allow everything from
> that namespace.)

I meant that if I have to either subclass or change Block.java then two 
independently developed extensions can not both be used in the same 
document.

> Remember, FOP is basically a compiler--like javac, you
> have to define its syntax it will accept, and that
> will require coding.  Also, the only difference
> between an XSL FO and an extension FO is that the
> latter hasn't been blessed by the W3C yet.  Both need
> validation and coding.

I don't mind having to write validation code, but I seriously mind 
having to write it in exsting FOP sources.

>>It has worked quite well before. Without changing
>>any of FOPs layout or 
>>area sources.
> 
> True.  But in the old version, FOP would happily
> accept, say, an fo:root as a child of an fo:block, or
> an fo:layout-master-set as a child of an fo:list-item,
> and subsequently NPE while processing.  That model
> simply had to change.  Nobody would respect/use a
> product that operates that way, or a product based on
> such a product.

Fine, but that can never be an argument for removing support for 
independant extensions.

>>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. 
> 
> 
> Yes it should, if fo:block is to be XSL compliant. 
> The Recommendation defines the content model (i.e.,
> the children) that fo:block is to follow and their
> ordering.  We modify that for the extension elements
> predefined within FOP--as we're allowed to. 

Then I, as an extension writer, also want to change the validation but 
without having to modify existing FOP sources. So the validation have to 
somehow be made plugable.

>>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.
>>
> 
> 
> Actually, we could do that--fairly simple--let's see
> what the other committers have to say.  We can add a
> boolean to FOUserAgent called disableValidation, have
> FOTreeBuilder read it every time it sees an FO in the
> stream, and on the basis of that decide whether or not
> to call vCN().  
> 
> I see two problems though:  (1) performance
> issue--this boolean will need to be read for *every*
> node in the FO document, 

I would guess that a check on a boolean for each node is a bit faster 
than calling vCN for each node. But I have not measured it.

> (2) FOP will be raising NPE
> and CCE errors for invalid FO -- it is strange for a
> program to have a switch that will allow it to blow up
> with errors, or otherwise allow itself to run in an
> invalid state.  Not many programs provide such an
> option--that may not generate much customer
> confidence.  But, again, let's see what others have to
> say.


>>All true, but to an extension writer it doesn't
>>really matter.
>>
> 
> 
> It does, because if FOP keeps blowing up left and
> right, users aren't going to use it (or will be worn
> down by it), committers aren't going to remain with it
> (or potential ones will stay away from it), and the
> progression of FOP will slow down to take care of
> these trivialities.
 >
> You rely on FOP for a lot of the functionality for
> your own work--we need to attract committers in order
> to have more of that.  Also, for people who plan to
> base their work on FOP, i.e., market a derivative of
> it with advanced functionality, it is important that
> FOP have a solid reputation.  If FOP isn't solid,
> people will be less likely to trust derivatives of it,
> even if the extensions are very helpful.

That is all good and fine, but none of it matters to me if FOP doesn't 
support dynamicly loaded extensions.

regards,
finn

Mime
View raw message