RE: [VOTE] Move ElementMapping initialization from Driver to FOTreeBuilder

[Victor Mote <vi...@outfitr.com>]

Glen Mazza wrote:

> But, this is a two-vote procedure because something
> else has to be done first:
>
> 1.)  Discontinue the dynamic discovery and run-time
> adding capability of ElementMappings.  The code
> currently allows you to add user-created
> ElementMappings to the FOTreeBuilder at run-time
> without changes to the source code.  I think we can
> turn off this feature for two reasons:
>
> (a) It doesn't appear to work without source code
> changes anyway -- I was suspecting, and Peter had
> confirmed
> (http://marc.theaimsgroup.com/?l=fop-dev&m=105467992322684&w=2),
> that dynamically adding mappings won't help unless the
> code understands the semantics of the new mappings,
> i.e., what the Area Tree needs to do with them.
>
> But users skilled and inclined enough to create
> user-defined ElementMappings can still do so by
> modifying the source code.

What about instream-foreign objects that get passed through? SVG is the only
one I know of, and it is hard-wired in already, but I'm not sure that this
capability should be lightly tossed. Please explain why this is a
prerequisite for the proposed move.

> (b) We're a bit overloaded already for 1.0 -- removing
> run-time ElementMapping configuration will allow us to
> keep focused on other areas.  ("Moving Part Reduction"
> design pattern, my favorite ;)

If it is gumming up the works, then OK. Otherwise, why remove it?

> Here's my +1.

I'll abstain pending further clarification.

> 2.)  Finally, move the code setting up the default
> element mappings from Driver class to FOTreeBuilder
> directly.  The Driver class will be
> ElementMapping-free.
>
> Here's my +1.

+1 (on part 2).

Victor Mote


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

Re: [VOTE] Move ElementMapping initialization from Driver to FOTreeBuilder

[Jeremias Maerki <de...@greenmail.ch>]

On 01.07.2003 06:46:52 Glen Mazza wrote:
> --- Victor Mote <vi...@outfitr.com> wrote:
> > 
> > What about instream-foreign objects that get passed
> > through? SVG is the only
> > one I know of, and it is hard-wired in already, but
> > I'm not sure that this
> > capability should be lightly tossed. 
> 
> Agreed.  But do dynamically added ElementMappings
> actually work, i.e., can we actually attach an 
> ElementMapping to FOP without changing FOP code?

We can. Have a look at mathml and plan in the examples directory. I've
started another one for krysalis-barcode.

I'm not quite ready to throw that functionality out. Keiron has done a
pretty good job improving the element extension facility in the redesign.
It's a lot better than the stuff in the maintenance branch which I'm
currently fighting with. So consider it a -0.5 for now (!) to remove the
dynamic addition of extensions.  For moving the code I'm +1.


Jeremias Maerki


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

RE: [VOTE] Move ElementMapping initialization from Driver to FOTreeBuilder

[Glen Mazza <gr...@yahoo.com>]

Thanks for voting.

--- Victor Mote <vi...@outfitr.com> wrote:
> 
> What about instream-foreign objects that get passed
> through? SVG is the only
> one I know of, and it is hard-wired in already, but
> I'm not sure that this
> capability should be lightly tossed. 

Agreed.  But do dynamically added ElementMappings
actually work, i.e., can we actually attach an 
ElementMapping to FOP without changing FOP code? To
see how dynamic discovery/run-time addition of
ElementMappings might work, I looked at
SVGElementMapping and ExtensionElementMapping, two of
the three already hardcoded.

SVGElementMapping, for example, includes these
libraries:

import org.apache.fop.fo.FONode;
import org.apache.fop.fo.ElementMapping;
import org.apache.fop.fo.FOTreeBuilder;

ExtensionElementMapping includes a Bookmark FO, which
needs these libraries:

import org.apache.fop.layoutmgr.LayoutHandler;
import org.apache.fop.fo.FONode;
import org.apache.fop.area.AreaTree;

ElementMappings appear just too wedded to the
application (definition and semantics) to be able to
be dynamically added run-time to FOP.  Even compiling
such classes separately appears difficult.


> Please explain
> why this is a
> prerequisite for the proposed move.
> 

Actually, it's not, but it might defeat some of the
goals of encapsulation.  We can indeed keep this
functionality in FOTreeBuilder--"dynamic discovery" of
ElementMappings could be carried out by FOTreeBuilder,
also, for run-time additions, one can call from code:

myFOTreeBuilder.AddElementMapping(...);

After the new API is nailed down, we may have similar
versions of these functions back into FOTreeBuilder
anyway, in particular to add/remove/modify *already
hardcoded* ElementMappings for speed optimizations,
etc, from the public API.  

But this is a separate issue--here, I would like the
committers to think about whether they would like
*dynamically* added ElementMappings in 1.0--my
inclination--not much more than that--is "no" right
now because I don't see how the current implementation
of them can work.

> > Here's my +1.
> 
> I'll abstain pending further clarification.
> 

Your current 0/+1 is noted...Feel free to change
either upon further review.

Glen


__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org