--- Finn Bock <[EMAIL PROTECTED]> 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
