xmlgraphics-fop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glen Mazza <grm7...@yahoo.com>
Subject Re: validateChildNode prevents extensions.
Date Sat, 28 Aug 2004 21:52:50 GMT

--- Finn Bock <bckfnn@worldonline.dk> wrote:
> 
> 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.
> 

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.

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

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

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.


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

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.

> > It's not like you are losing dynamic run-time
> > loadability here, 
> 
> Oh, yes I am.
> 

You will need to better clarify this, because you just
said above that you needed to change source code
anyway to accomodate your new element.

> 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.  But it
still has to follow a content model.  The "sit back,
have a beer, and let everything pass through" mode of
validation I'm not too keen on.  ;)

> I promise that I will not
> post the resulting 
> bugs to Bugzilla.
> 

Good, now we'll just need the promises of 500,000
users as well. ;)  You are too smart not to realize
that a non-validating XSL parser is going to generate
lots of NPE/CCE bugs, subtle and otherwise for the
committers and user community to have to deal with. 
Time spent fixing this junk will not be time spent in
the layout and renderers, etc.  That will hurt your
goals, as well as degrade FOP.  

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


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

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.

Sorry again for the long post.

Glen


Mime
View raw message