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 Mon, 30 Aug 2004 10:38:47 GMT

--- Finn Bock <bckfnn@worldonline.dk> wrote:
> [Glen]
> 
> > From what I understand a program may not change
> its
> > own source code while it is running so we may not
> have
> > complete freedom for everything.
> 
> I don't know exactly what you mean. I don't think
> that such a thing is 
> required to have extensible validation for
> extensions.
> 

I agree with you there.  But let me elaborate a bit on
this point--coming in as a committer, I didn't
understand the benefits of dynamically loading
extension FO's because you would still need to alter
the area tree, layout, renderers, etc. in order to
accomodate the new element.  But that code, once
loaded, cannot be dynamically changed while running. 
(I'm not talking here about fo:i-f-o children, which
just get sent off to a different processor)  

For example, let's say we remove the fox:bookmarks
from our code, as well as the code from
AreaTreeHandler.java (and a few other places) that
work with it.  Instead, we dynamically load this
element.  While we can load the element itself, we
will not be able to dynamically rewrite the code in
AreaTreeHandler, renderers, layout, etc. to accomodate
this new element, or arbitrarily any new element we
discover.  (You've noticed that already, as you've had
to hardcode FOP beforehand to different renderers,
etc.)  So dynamic discovery for non fo:i-f-o use will
not be a complete nirvana for an extension
writer--even if not validation necessarily, some
(hardcoded) work beforehand will still be needed.

Glen Mazza


Mime
View raw message