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 14:15:03 GMT
Oh, when I meant "alter the system" I also meant
adding classes, using different classes, etc., i.e.,
some things need to be done beforehand to accomodate a
new element.

BTW, without divulging too much that may hurt your
interests, would you mind explaining your reluctance
to just modify FOP source (replace classes, etc.) for
what you are trying to market?  Is it licensing
issues--or is it more for programmatic style/user
convenience?  I want to better understand your
reluctance on this matter.


--- 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.
> [Glen]
> > 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,
> Not for the extension I have written. Additional
> area classes, but no 
> changes or replacing of existing classes.
> > layout, 
> No. Additional layoutmanagers, but no changes to
> existing LMs.
> > renderers, 
> No. I wrote my own PDF renderer that is using iText
> as PDF library. So 
> no changes to existing code, but I did have to
> replace the pdf renderer.

View raw message