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 Sun, 29 Aug 2004 23:53:04 GMT
--- Jeremias Maerki <dev.jeremias@greenmail.ch> 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


Mime
View raw message