xmlgraphics-fop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Finn Bock <bck...@worldonline.dk>
Subject Re: validateChildNode prevents extensions.
Date Mon, 30 Aug 2004 12:42:35 GMT

>>[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.

Clearly the renderer doesn't support extension areas, but that is a 
weakness in the design of the renderer.

> 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.  

The tree extension code in AreaTreeHandler is generally usefull support 
code. I believe that the addBookmarks() and createBookmarkData() once 
lived in Bookmarks.java. Don't know when or why it was moved into the core.

> 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.)  

Hardcode? I did this (in a slightly older version of head):

     Driver driver = new Driver();
     driver.initialize();
     driver.setRenderer(new ITextRenderer());
     driver.addElementMapping(new MyElementMapping());
     driver.render(...);

How is that hardcoding. That is a simple configuration to my 
requirements of the Driver class (as it was called at the time).

> 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.

The 1. rule of holes is to stop digging when we find ourself in one.

The current lack of nirvana is no reason to keep digging us deeper into 
the hole.

Instead we should keep the support for extension in the FO classes and 
slowly work on adding support for extension areas to the renderer framework.

regards,
finn

Mime
View raw message