--- Jeremias Maerki <[EMAIL PROTECTED]> wrote: > > On 29.08.2004 20:57:54 Simon Pepping wrote: > > On Sun, Aug 29, 2004 at 08:15:38PM +0200, > J.Pietschmann wrote: > > > Glen Mazza wrote: > > > >You have a new FO, you're going to need to code > for > > > >them--including ordering and cardinality--in > those > > > >parents that accept them, > > > > > > This does *not* necessarily mean that *you* > should arrange > > > that the extension writer has to replace core FO > classes. > > > In fact do either: > > > 1. Declare FOP wont support extensions except in > > > instream-foreign-object, ever, or
No, we just summarize the steps needed to modify FOP by changing its source, or, as Finn prefers, attaching another library. Fortunately or unfortunately, though, an FO Processor has a grammar one has to follow. Adding an FO-based element requires the grammar to change--indeed, you have a brand-new FO processor when you bring in a new element. Thankfully we appear to be all in agreement on this--it is just a question of implementation. I still feel the overall complexity involved with subclassing the Parent FO in Finn's JAR remains much less than moving from parent-based to child-based validation. Further ameliorating this is that many times you may want to override the parent anyway--for more hooks or other changes, etc. But Finn is working on other solutions for us right now--let's see what he can come up with. It must be stated, though, that 99 out of 100 users will not be writing extensions. Their needs, a solid FOP out relatively soon, must not be ignored. Glen Mazza
