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
