Still need DOM Tree processing?

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

Team,

We allow--and have for many years--for input
processing of FO documents in the form of DOM trees. 
Several months back I created an example [1] of a
"Hello World" FO document to show how this
functionality might be used.

The (well-written) classes which provide this
functionality, tools.DocumentReader and
tools.DocumentInputSource [2], date to March 2001 when
it was factored out of code in Apps.Driver.  The
original code in Driver that provided this
functionality predates 2000, when original author
James Tauber was coding FOP [3].

But does anyone generate FO documents via DOM Trees
anymore?  This style of coding appears to come from
the days that SAX wasn't as well known as DOM.  The
example I gave would be very cumbersome and
hard-to-maintain for any non-trivial sized FO
document.  Although one potential use could be reading
an FO file into a DOM Tree, navigating the tree, and
manipulating its values, it would appear the standard
today in these cases would be to just use xsl:param
and setParameter() as here [4].

If this style of coding is obsolete, I would like to
remove this functionality from our API in HEAD--we can
return it back fairly easily if we start getting hate
mail as FOP 1.0 solidifies and gets more use. In
addition to removing the two classes above, it would
also allow me to simplify/streamline apps.Driver a bit
more, and I can also remove my example given on the
Embed page.

Thanks,
Glen

[1]
http://cvs.apache.org/viewcvs.cgi/xml-fop/examples/embedding/java/embedding/ExampleDOM2PDF.java?annotate=1.7#81

[2]
http://cvs.apache.org/viewcvs.cgi/xml-fop/src/java/org/apache/fop/tools/

[3]
http://cvs.apache.org/viewcvs.cgi/xml-fop/src/org/apache/fop/apps/Attic/Driver.java?annotate=1.6#242

[4] 
http://cvs.apache.org/viewcvs.cgi/xml-fop/examples/embedding/java/embedding/ExampleXML2PDF.java?annotate=1.8#82

Re: Still need DOM Tree processing?

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

--- Jeremias Maerki <de...@greenmail.ch> wrote:
>
> > But FOP is not XML Commons, and IMO external users
> > should not be directly latching on to non-XSL
> portions
> > (i.e., not fonts or hyphenation, etc., things that
> we
> > are expected to share) of our code that way.  That
> > would limit our ability to
> modify/optimize/simplify
> > the code to provide a solid XSL implementation.
> 
> I'm not sure I understand this paragraph correctly.
> Does that mean that
> you will be against factoring out certain basic
> components from FOP into
> a separate area so they can be more easily reused by
> others and improved
> by people not really seeing through FOP's code
> forrest?
> 

No, what you're suggesting is the way I would propose
it.  In a typical case of reuse, code would be taken
out of FOP, sent to XML Commons or the XML Graphics
components, and imported back into FOP as a library. 
Possible exceptions are those "by definition" classes
that FOP should be exposing, by virtue of the type of
application it is.  As you can tell, I'm fuzzy on
this.  Let's discuss these on a case-by-case basis
after XML Graphics forms.

It's just our FOP infrastructure/internal code that I
wouldn't want users to be directly importing into
their apps:  that code is subject to change, renaming,
removal, etc.  

I judged the two classes in question to be more or
less just an internal implementation of how we were
handling things.  "import
org.apache.fop.apps/tools.DocumentReader" from user
code is not something I would want us to be supporting
in the future.  Supplying identity transform
alternatives is outside the scope of FOP; in the
unlikely event we ever get demand for these two
classes we can send those classes to XML Commons, so
the user can "import org.apache.xml.commons.xxxx"
instead.

Glen

Re: Still need DOM Tree processing?

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

On 07.07.2004 05:41:11 Glen Mazza wrote:
> --- Jeremias Maerki <de...@greenmail.ch> wrote:
> >
> > Using
> > a DOMSource and a SAXResult with an identity
> > transformer. 
> >
> 
> Do we already have an example for this one?  I'm not
> sure of what you mean--are you saying that Manuel can
> continue doing exactly what he's doing (slurping a FO
> file into a DOM Tree, manipulating the tree by adding
> RDBMS values to it, then sending the DOM Tree off to
> FOP to be published) with what you mention above?

Yes, exactly. Take the XML2PDF example. I'm copying the important part
and only have to change two lines to (1) use the identity transformer
instead of an XSLT stylesheet and (2) using a DOM as source instead of
an XML file.

driver.setOutputStream(out);

// Setup XSLT
TransformerFactory factory = TransformerFactory.newInstance();
//Transformer transformer = factory.newTransformer(new StreamSource(xsltfile));
Transformer transformer = factory.newTransformer(); //identity transformer

// Setup input for XSLT transformation
//Source src = new StreamSource(xmlfile);
Source src = new DOMSource(mydomnode);

// Resulting SAX events (the generated FO) must be piped through to FOP
Result res = new SAXResult(driver.getContentHandler());

// Start XSLT transformation and FOP processing
transformer.transform(src, res);


> Also, under the hood, do you suspect that the identity
> transformer is the same thing as our two classes?  I'm
> far from an expert at this.

Not the same, but has the same effect.

> > On the
> > other side, the two
> > classes are perfectly usable and useful stand-alone
> > outside of FOP.
> > 
> 
> I would guess those two classes are a dime a dozen,
> probably in 100 articles and books.  But a non-FOP
> user can always take the source code and incorporate
> them in his/her program.

That's right.

> But FOP is not XML Commons, and IMO external users
> should not be directly latching on to non-XSL portions
> (i.e., not fonts or hyphenation, etc., things that we
> are expected to share) of our code that way.  That
> would limit our ability to modify/optimize/simplify
> the code to provide a solid XSL implementation.

I'm not sure I understand this paragraph correctly. Does that mean that
you will be against factoring out certain basic components from FOP into
a separate area so they can be more easily reused by others and improved
by people not really seeing through FOP's code forrest?

> > In the end I don't see what is gained by moving
> > these two classes around
> > and by reducing their visibility. 
> 
> My thinking:
> 
> We can get rid of them in the future, without worrying
> about backwards compatibility.

Ok.

> We can move, rename, merge, modify them without
> worrying about external use.

Yes, but what's the benefit about moving them around when they were in a
place where nobody was bothered by them and they were doing their job?

> Fewer moving parts and fewer access paths means fewer
> bugs and less confusion both on the FOP-USER list as
> well as with developers.

Well, these two classes are certainly not cause to any pain. If I've
seen that correctly the code has never been semantically changed sence
its separation from the Driver code in 2001. Kelly Campbell wrote then: 
"Refactored Driver to simplify usage required for other apps to
integrate Fop."

> Also, we're placing them precisely in the package, and
> the only package, in which they're being called.  This
> makes the packages less dependent on each other. 
> 
> But the visibility is actually less important to me
> than the location.  If it would make you more
> comfortable, I'm willing to make them public, but I
> would prefer them to stay in apps.  (We can also wait
> first until we get hate mail--exposing them is very
> simple--but if we never get such mail we know they are
> no longer needed.)

There is a good chance that nobody uses this code at all, yes. But in
all no strong points IMHO to motivate this change. NTARS.

> > It's simply a fact
> > that many people
> > still work with a DOM and I know a few programmers
> > who are very hard to
> > talk into adopting a different style of dealing with
> > XML.
> 
> They won't need to--we will happily continue to be
> supporting DOM Trees within FOP. Moving them to apps
> also shows their first-class ranking alongside
> XSLTInputHandler and FOInputHandler.

Ok, I will shut up about this now.


Jeremias Maerki

Re: Still need DOM Tree processing?

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

--- Jeremias Maerki <de...@greenmail.ch> wrote:
>
> Using
> a DOMSource and a SAXResult with an identity
> transformer. 
>

Do we already have an example for this one?  I'm not
sure of what you mean--are you saying that Manuel can
continue doing exactly what he's doing (slurping a FO
file into a DOM Tree, manipulating the tree by adding
RDBMS values to it, then sending the DOM Tree off to
FOP to be published) with what you mention above?

Also, under the hood, do you suspect that the identity
transformer is the same thing as our two classes?  I'm
far from an expert at this.

> On the
> other side, the two
> classes are perfectly usable and useful stand-alone
> outside of FOP.
> 

I would guess those two classes are a dime a dozen,
probably in 100 articles and books.  But a non-FOP
user can always take the source code and incorporate
them in his/her program.

But FOP is not XML Commons, and IMO external users
should not be directly latching on to non-XSL portions
(i.e., not fonts or hyphenation, etc., things that we
are expected to share) of our code that way.  That
would limit our ability to modify/optimize/simplify
the code to provide a solid XSL implementation.

> In the end I don't see what is gained by moving
> these two classes around
> and by reducing their visibility. 

My thinking:

We can get rid of them in the future, without worrying
about backwards compatibility.

We can move, rename, merge, modify them without
worrying about external use.

Fewer moving parts and fewer access paths means fewer
bugs and less confusion both on the FOP-USER list as
well as with developers.

Also, we're placing them precisely in the package, and
the only package, in which they're being called.  This
makes the packages less dependent on each other. 

But the visibility is actually less important to me
than the location.  If it would make you more
comfortable, I'm willing to make them public, but I
would prefer them to stay in apps.  (We can also wait
first until we get hate mail--exposing them is very
simple--but if we never get such mail we know they are
no longer needed.)

> It's simply a fact
> that many people
> still work with a DOM and I know a few programmers
> who are very hard to
> talk into adopting a different style of dealing with
> XML.

They won't need to--we will happily continue to be
supporting DOM Trees within FOP. Moving them to apps
also shows their first-class ranking alongside
XSLTInputHandler and FOInputHandler.

Thanks,
Glen

Re: Still need DOM Tree processing?

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

A bit late to react but I'm not 100% happy with moving the two classes
into apps. I was a bit surprised at the time you introduced the DOM
example because the same functionality could be provided via JAXP: Using
a DOMSource and a SAXResult with an identity transformer. The examples
were meant to show best practices by using widely known APIs. FOP's
direct support for DOM predates JAXP and, today, is presented to our
users as a convenience only (my opinion). On the other side, the two
classes are perfectly usable and useful stand-alone outside of FOP.

In the end I don't see what is gained by moving these two classes around
and by reducing their visibility. It's simply a fact that many people
still work with a DOM and I know a few programmers who are very hard to
talk into adopting a different style of dealing with XML.

On 04.07.2004 22:23:17 Glen Mazza wrote:
> Team,
> 
> We allow--and have for many years--for input
> processing of FO documents in the form of DOM trees. 
> Several months back I created an example [1] of a
> "Hello World" FO document to show how this
> functionality might be used.
> 
> The (well-written) classes which provide this
> functionality, tools.DocumentReader and
> tools.DocumentInputSource [2], date to March 2001 when
> it was factored out of code in Apps.Driver.  The
> original code in Driver that provided this
> functionality predates 2000, when original author
> James Tauber was coding FOP [3].
> 
> But does anyone generate FO documents via DOM Trees
> anymore?  This style of coding appears to come from
> the days that SAX wasn't as well known as DOM.  The
> example I gave would be very cumbersome and
> hard-to-maintain for any non-trivial sized FO
> document.  Although one potential use could be reading
> an FO file into a DOM Tree, navigating the tree, and
> manipulating its values, it would appear the standard
> today in these cases would be to just use xsl:param
> and setParameter() as here [4].
> 
> If this style of coding is obsolete, I would like to
> remove this functionality from our API in HEAD--we can
> return it back fairly easily if we start getting hate
> mail as FOP 1.0 solidifies and gets more use. In
> addition to removing the two classes above, it would
> also allow me to simplify/streamline apps.Driver a bit
> more, and I can also remove my example given on the
> Embed page.



Jeremias Maerki

Re: Still need DOM Tree processing?

[Simon Pepping <sp...@leverkruid.nl>]

On Mon, Jul 05, 2004 at 11:20:26AM -0700, Glen Mazza wrote:
> Thanks for the information.  Working with a DOM tree
> saves one the step of needing to place input data into
> XML first.  So retaining this functionality in 1.0
> will keep the flexibility to users in how they can
> approach a report-generation task.  I guess we should
> keep it in then.

I support that decision. It is one more entry point for apps. Of
course they can fire off their own SAX events, but if they have a DOM
tree and FOP does it for them, that is nice.

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl

Re: Still need DOM Tree processing?

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

Thanks for the information.  Working with a DOM tree
saves one the step of needing to place input data into
XML first.  So retaining this functionality in 1.0
will keep the flexibility to users in how they can
approach a report-generation task.  I guess we should
keep it in then.

Thanks,
Glen

--- Manuel Mall <mm...@arcus.com.au> wrote:
> Glen,
> 
> A 1. We do preload an FO file into a DOM tree,
> navigate it, do manipulations, and then send it
> off to be published into PDF.
> 
> A 2. At the time it seemed the easier way of doing
> it.
> Would we still be doing it again instead of using
> XSLT?
> Hmm, our input data is not in XML but comes from a
> RDBMS and other sources. So we would have to convert
> this into custom XML and restructure our current FO
> files to become XSLT stylesheets. Its doable and
> would
> certainly be more "standards compliant". Would it be
> simpler / easier? As it stands now for any
> formatting
> changes we just edit the FO file. In future it would
> mean
> editing the XSL file => No loss or gain. For data
> structure
> changes we need to modify the FO file and the code 
> setting up the final DOM tree. In future we would
> need
> to change the XSL and the code creating the XML 
> from the data => Again no loss or gain.
> 
> Manuel
> ----- Original Message ----- 
> From: "Glen Mazza" <gr...@yahoo.com>
> 
> 
> > Thanks--you're the first I've heard using it.
> > 
> > May I ask:  
> > 
> > 1) Do you manually create the FO document from
> scratch
> > similar to the first example I gave in my previous
> > email?  Or, do you preload an FO file into a DOM
> tree,
> > navigate it, do minor manipulations, and then send
> it
> > off to be published into PDF?
> > 
> > 2) Is using DOM Trees an optimal way for you to do
> > your work, or is it just legacy code you don't
> wish to
> > disturb?  (I.e., if you had to rewrite it from the
> > beginning, would you still use DOM Trees?)
> > 
> > Glen
> > 
> > --- Manuel Mall <mm...@arcus.com.au> wrote:
> > > 
> > > From: "Glen Mazza" <gr...@yahoo.com>
> > > 
> > > 
> > > > Team,
> > > > 
> > > > But does anyone generate FO documents via DOM
> > > Trees
> > > > anymore?
> > > 
> > > Yes, we do in a back office "fop intensive"
> server
> > > application.
> > > 
> > > Manuel
> > > 
> 
> 

Re: Still need DOM Tree processing?

[Manuel Mall <mm...@arcus.com.au>]

Glen,

A 1. We do preload an FO file into a DOM tree,
navigate it, do manipulations, and then send it
off to be published into PDF.

A 2. At the time it seemed the easier way of doing it.
Would we still be doing it again instead of using XSLT?
Hmm, our input data is not in XML but comes from a
RDBMS and other sources. So we would have to convert
this into custom XML and restructure our current FO
files to become XSLT stylesheets. Its doable and would
certainly be more "standards compliant". Would it be
simpler / easier? As it stands now for any formatting
changes we just edit the FO file. In future it would mean
editing the XSL file => No loss or gain. For data structure
changes we need to modify the FO file and the code 
setting up the final DOM tree. In future we would need
to change the XSL and the code creating the XML 
from the data => Again no loss or gain.

Manuel
----- Original Message ----- 
From: "Glen Mazza" <gr...@yahoo.com>


> Thanks--you're the first I've heard using it.
> 
> May I ask:  
> 
> 1) Do you manually create the FO document from scratch
> similar to the first example I gave in my previous
> email?  Or, do you preload an FO file into a DOM tree,
> navigate it, do minor manipulations, and then send it
> off to be published into PDF?
> 
> 2) Is using DOM Trees an optimal way for you to do
> your work, or is it just legacy code you don't wish to
> disturb?  (I.e., if you had to rewrite it from the
> beginning, would you still use DOM Trees?)
> 
> Glen
> 
> --- Manuel Mall <mm...@arcus.com.au> wrote:
> > 
> > From: "Glen Mazza" <gr...@yahoo.com>
> > 
> > 
> > > Team,
> > > 
> > > But does anyone generate FO documents via DOM
> > Trees
> > > anymore?
> > 
> > Yes, we do in a back office "fop intensive" server
> > application.
> > 
> > Manuel
> > 

Re: Still need DOM Tree processing?

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

Thanks--you're the first I've heard using it.

May I ask:  

1) Do you manually create the FO document from scratch
similar to the first example I gave in my previous
email?  Or, do you preload an FO file into a DOM tree,
navigate it, do minor manipulations, and then send it
off to be published into PDF?

2) Is using DOM Trees an optimal way for you to do
your work, or is it just legacy code you don't wish to
disturb?  (I.e., if you had to rewrite it from the
beginning, would you still use DOM Trees?)

Glen

--- Manuel Mall <mm...@arcus.com.au> wrote:
> 
> From: "Glen Mazza" <gr...@yahoo.com>
> 
> 
> > Team,
> > 
> > But does anyone generate FO documents via DOM
> Trees
> > anymore?
> 
> Yes, we do in a back office "fop intensive" server
> application.
> 
> Manuel
> 
> 
> 

Re: Still need DOM Tree processing?

[Manuel Mall <mm...@arcus.com.au>]

From: "Glen Mazza" <gr...@yahoo.com>


> Team,
> 
> But does anyone generate FO documents via DOM Trees
> anymore?

Yes, we do in a back office "fop intensive" server application.

Manuel