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 Jason Harrop <jh...@gmail.com> on 2010/11/19 05:35:10 UTC
FOP + JAXB
Hello
I have used the JAXB tool XJC to generate a set of classes which
represent http://svn.apache.org/repos/asf/xmlgraphics/fop/trunk/src/foschema/fop.xsd
As wikipedia explains, "Java Architecture for XML Binding (JAXB)
allows Java developers to map Java classes to XML representations.
JAXB provides two main features: the ability to marshal Java objects
into XML and the inverse, i.e. to unmarshal XML back into Java
objects". JAXB is similar to XMLBeans. It is JSR-222.
You can see the Java classes for fop.xsd at
http://dev.plutext.org/svn/docx4j/trunk/docx4j/src/xslfo/org/plutext/jaxb/xslfo/
My motivation was initially to be able to create somewhat complex
layout master set; see
http://dev.plutext.org/svn/docx4j/trunk/docx4j/src/main/java/org/docx4j/convert/out/pdf/viaXSLFO/LayoutMasterSetBuilder.java
I'm planning to publish the code somewhere as a code base independent
from docx4j. Is there any interest in having it as part of FOP?
What if FOP could ingest these Java objects directly (ie without the
having to be marshalled first)?
If there is no interest, that's fine. I'll just put the code on
Google Code, say.
cheers . Jason
Re: FOP + JAXB
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
Hi Jason,
yes, generating a SAX stream from JAXB should be easy. But personally, I
would never write Java code that produces XSL-FO for real-life documents
because it would be too tedious and very hard to maintain. In every
single case, I would see to it that I can produce XML data and put that
through an XSLT stylesheet.
Looking at the generated JAXB classes from the plutext SVN repo, I can
see how all inheritable properties have to be repeated for each and
every FO object. Jason, have you thought about how much memory each of
these objects consume? Most of them will not ever be set so are just
wasting space. I really think this approach doesn't make sense. You
would at least be a little better off doing some code generation of your
own to provide Java interfaces and FO object classes that are operating
on an XML DOM as backend. That way, you'd have a sparse approach to
these objects. You might even want to investigate directly working with
FOP's FO tree.
On 19.11.2010 11:59:20 Peter Hancock wrote:
> Hi Jason,
>
> I can imagine your motivation for creating a representation of an fo
> tree in a java application
> however feeding this into FOP directly would perhaps be a little
> wastful from FOP's point of view:
> FOP uses SAX to parse the fo input and then builds an internal
> representation of the FO tree.
> This is not just a deserialization of the tree into java beans-
> the FO Tree classes provides methods that capture the semantic
> complexity of the fo structure,
> one that cannot be represented in an .xsd.
>
> Navigating a DOM like structure and then generating the richer FOTree
> would promote an extra layer of processing
> and memory consumption, and is something we would want to avoid when
> dealing with large documents.
>
> This is not to say there is no value with your approach to generating
> fo. Maybe you could navigate your tree and generate sax events
> that can be handled by FOP's FOTree builder- I think this can be
> achieved in fairly straigt forward way, although I am no expert in
> chaining SAX processors.
> Perhaps a bit of bridging code maybe required and perhaps FOP would
> benefit from this.
>
> Hopefully some one else in the FOP community can confirm my thoughts
> here with perhaps a pointer for getting started.
>
> Pete
>
>
> On Fri, Nov 19, 2010 at 4:35 AM, Jason Harrop <jh...@gmail.com> wrote:
> > Hello
> >
> > I have used the JAXB tool XJC to generate a set of classes which
> > represent http://svn.apache.org/repos/asf/xmlgraphics/fop/trunk/src/foschema/fop.xsd
> >
> > As wikipedia explains, "Java Architecture for XML Binding (JAXB)
> > allows Java developers to map Java classes to XML representations.
> > JAXB provides two main features: the ability to marshal Java objects
> > into XML and the inverse, i.e. to unmarshal XML back into Java
> > objects". JAXB is similar to XMLBeans. It is JSR-222.
> >
> > You can see the Java classes for fop.xsd at
> > http://dev.plutext.org/svn/docx4j/trunk/docx4j/src/xslfo/org/plutext/jaxb/xslfo/
> >
> > My motivation was initially to be able to create somewhat complex
> > layout master set; see
> > http://dev.plutext.org/svn/docx4j/trunk/docx4j/src/main/java/org/docx4j/convert/out/pdf/viaXSLFO/LayoutMasterSetBuilder.java
> >
> > I'm planning to publish the code somewhere as a code base independent
> > from docx4j. Is there any interest in having it as part of FOP?
> >
> > What if FOP could ingest these Java objects directly (ie without the
> > having to be marshalled first)?
> >
> > If there is no interest, that's fine. I'll just put the code on
> > Google Code, say.
> >
> > cheers . Jason
> >
Jeremias Maerki
Re: FOP + JAXB
Posted by Peter Hancock <pe...@gmail.com>.
Hi Jason,
I can imagine your motivation for creating a representation of an fo
tree in a java application
however feeding this into FOP directly would perhaps be a little
wastful from FOP's point of view:
FOP uses SAX to parse the fo input and then builds an internal
representation of the FO tree.
This is not just a deserialization of the tree into java beans-
the FO Tree classes provides methods that capture the semantic
complexity of the fo structure,
one that cannot be represented in an .xsd.
Navigating a DOM like structure and then generating the richer FOTree
would promote an extra layer of processing
and memory consumption, and is something we would want to avoid when
dealing with large documents.
This is not to say there is no value with your approach to generating
fo. Maybe you could navigate your tree and generate sax events
that can be handled by FOP's FOTree builder- I think this can be
achieved in fairly straigt forward way, although I am no expert in
chaining SAX processors.
Perhaps a bit of bridging code maybe required and perhaps FOP would
benefit from this.
Hopefully some one else in the FOP community can confirm my thoughts
here with perhaps a pointer for getting started.
Pete
On Fri, Nov 19, 2010 at 4:35 AM, Jason Harrop <jh...@gmail.com> wrote:
> Hello
>
> I have used the JAXB tool XJC to generate a set of classes which
> represent http://svn.apache.org/repos/asf/xmlgraphics/fop/trunk/src/foschema/fop.xsd
>
> As wikipedia explains, "Java Architecture for XML Binding (JAXB)
> allows Java developers to map Java classes to XML representations.
> JAXB provides two main features: the ability to marshal Java objects
> into XML and the inverse, i.e. to unmarshal XML back into Java
> objects". JAXB is similar to XMLBeans. It is JSR-222.
>
> You can see the Java classes for fop.xsd at
> http://dev.plutext.org/svn/docx4j/trunk/docx4j/src/xslfo/org/plutext/jaxb/xslfo/
>
> My motivation was initially to be able to create somewhat complex
> layout master set; see
> http://dev.plutext.org/svn/docx4j/trunk/docx4j/src/main/java/org/docx4j/convert/out/pdf/viaXSLFO/LayoutMasterSetBuilder.java
>
> I'm planning to publish the code somewhere as a code base independent
> from docx4j. Is there any interest in having it as part of FOP?
>
> What if FOP could ingest these Java objects directly (ie without the
> having to be marshalled first)?
>
> If there is no interest, that's fine. I'll just put the code on
> Google Code, say.
>
> cheers . Jason
>