You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Glen Mazza <gr...@yahoo.com> on 2003/06/30 23:12:59 UTC
[VOTE] Move ElementMapping initialization from Driver to FOTreeBuilder
Team,
As mentioned earlier, I would like to pull out
FOTreeBuilder's ElementMapping initialization from
Apps.Driver, and instead encapsulate it within
FOTreeBuilder directly.
[Note: Alt-design no longer uses ElementMappings--but
this change does not preclude switching to
alt-design's method: if we do make such a switch,
instead of pulling out ElementMapping code from both
Driver and FOTreeBuilder, we'll just pull out the code
from FOTreeBuilder.]
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.
(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 ;)
Here's my +1.
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.
Thanks,
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
Re: [VOTE] Move ElementMapping initialization from Driver to FOTreeBuilder
Posted by "Peter B. West" <pb...@powerup.com.au>.
Glen Mazza wrote:
> --- "Peter B. West" <pb...@powerup.com.au> wrote:
>
>>That the semantics of the extensions have to be
>>realized somewhere is
>>tautological, even if those semantics are "filter
>>out."
>>
>
>
> "Tautological"? Very good, Peter, you got me--it's
> rare when someone makes me need to look up a word in
> the dictionary!
Aw, shucks. I'm blushing.
> (For the benefit of the native German speakers on the
> list, "tautological" means "tautologisch". ;)
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html
---------------------------------------------------------------------
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
Posted by Glen Mazza <gr...@yahoo.com>.
--- "Peter B. West" <pb...@powerup.com.au> wrote:
>
> That the semantics of the extensions have to be
> realized somewhere is
> tautological, even if those semantics are "filter
> out."
>
"Tautological"? Very good, Peter, you got me--it's
rare when someone makes me need to look up a word in
the dictionary!
(For the benefit of the native German speakers on the
list, "tautological" means "tautologisch". ;)
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
Re: [VOTE] Move ElementMapping initialization from Driver to FOTreeBuilder
Posted by "Peter B. West" <pb...@powerup.com.au>.
J.Pietschmann wrote:
> Glen Mazza wrote:
>
>> 1.) Discontinue the dynamic discovery and run-time
>> adding capability of ElementMappings.
>
>
> -1
>
>> (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.
Which, in the case of existing, working, extensions, it does.
That the semantics of the extensions have to be realized somewhere is
tautological, even if those semantics are "filter out."
> The answer is: it depends. If the areas the extension element
> creates can be handled by the renderer, and the extension is
> put into places where the FO content model isn't yet enforced
> by the code, there is no problem to add it without further
> code changes.
>
> The MathML and Plan samples actually depend on this.
Hmmm.
Peter
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html
---------------------------------------------------------------------
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
Posted by Glen Mazza <gr...@yahoo.com>.
Thanks for voting--it looks like we'll continue with
dynamic adding of element mappings (thanks to Joerg
and Jeremias for pointing out that the functionality
*does* work--which was my major concern), but I'll
move the ElementMapping code out of Driver and into
FOTreeBuilder.
--- "J.Pietschmann" <j3...@yahoo.de> wrote:
>
> -0
> I don't think it matters much. If the new API comes
> to fly,
> the Driver class will be deprecated anyway.
>
Indeed--hopefully getting this code out of Driver will
help facilitate its deprecation.
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
Re: [VOTE] Move ElementMapping initialization from Driver to FOTreeBuilder
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Glen Mazza wrote:
> 1.) Discontinue the dynamic discovery and run-time
> adding capability of ElementMappings.
-1
> (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.
The answer is: it depends. If the areas the extension element
creates can be handled by the renderer, and the extension is
put into places where the FO content model isn't yet enforced
by the code, there is no problem to add it without further
code changes.
The MathML and Plan samples actually depend on this.
> (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 ;)
I don't think dynamic element mapping adds all that much overload.
> 2.) Finally, move the code setting up the default
> element mappings from Driver class to FOTreeBuilder
> directly. The Driver class will be
> ElementMapping-free.
-0
I don't think it matters much. If the new API comes to fly,
the Driver class will be deprecated anyway.
J.Pietschmann
---------------------------------------------------------------------
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
Posted by 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
Posted by 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
RE: [VOTE] Move ElementMapping initialization from Driver to FOTreeBuilder
Posted by 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