This is part of The Pile, a partial archive of some open source mailing lists and newsgroups.
To: <modperl@apache.org>
From: "Jeffrey W. Baker" <jwbaker@acm.org>
Subject: Using DOM to build your output documents
Date: Wed, 3 Oct 2001 16:43:41 -0700 (PDT)
I believe that the canonical way to output a document using any web
scripting language (Perl CGI, mod_perl, PHP, ASP, etc.) is to simply print
out your markup, like this fictional example:
while (my $row = $sth->fetchrow_arrayred()) {
print "<tr><td>$row->[0]</td><td>$row->[1]</td></tr>\n";
}
There are two main drawbacks to this style of output. The first is that
print() can mean a trip down the output stack and back up. The second is
the unavoidable linearity output. There is no way to back up and change
something once you have decided to print it.
In my more recent web sites, I have been taking a slightly different
approach by building the document from scratch using the DOM, and printing
the DOM tree out at the end of the program. I perceive several
advantages:
* I can add or remove content and markup anywhere in the document at any
time.
* I avoid I/O functions until the final batch I/O at the end.
* I never have markup errors because the DOM tree always prints itself out
properly.
I'd love to hear any other experiences with using the DOM to build output
from scratch. I'd also like to hear people's opinions on XML::DOM (I
think it stinks and I've replaced it with a C DOM implementation).
-jwb
===
To: "Jeffrey W. Baker" <jwbaker@acm.org>
From: DeWitt Clinton <dewitt@unto.net>
Subject: Re: Using DOM to build your output documents
Date: Wed, 3 Oct 2001 20:16:28 -0400
On Wed, Oct 03, 2001 at 04:43:41PM -0700, Jeffrey W. Baker wrote:
> I'd also like to hear people's opinions on XML::DOM (I think it
> stinks and I've replaced it with a C DOM implementation).
You just proved that you already know everything you need to on the
subject of XML::DOM. :)
Seriously though, what C DOM implementation did you choose and how did
you integrate it with your Perl code?
I've long since abandoned XML::DOM and use things XML::Parser::PerlSAX
instead, but that doesn't achieve what you are talking about vis-a-vis
building up documents element by element. For output generation, I
still tend to push data into a template engine such as Embperl or
Template::Toolkit and use embedded control structures to manipulate
that data. Interestingly, the company I used to work at (eZiba) just
ported their front-end over to Mason and ended up somewhere in-between
-- i.e., reusable page components that they build up at run-time.
Check out the Avacet's (www.avacet.com) TemplateService for an example
of the push model in action.
Cheers,
-DeWitt
===
To: "Jeffrey W. Baker" <jwbaker@acm.org>
From: Chris Winters <chris@cwinters.com>
Subject: Re: Using DOM to build your output documents
Date: Thu, 4 Oct 2001 00:49:44 -0400
* Jeffrey W. Baker (jwbaker@acm.org) [011003 19:52]:
> I'd love to hear any other experiences with using the DOM to build output
> from scratch. I'd also like to hear people's opinions on XML::DOM (I
> think it stinks and I've replaced it with a C DOM implementation).
I can't speak to XML::DOM, but I used XMLC in Java to do this and
there were aspects that were pretty nifty. In particular, building a
list-type structure (table rows in particular) and then feeding it to
a visitor process that modified the properites of each item worked
really well.
XMLC works by compiling an XML document to a Java class which you then
manipulate. This was excellent for working with designers, since they
didn't have code or looping structures or anything cluttering up the
HTML. Just some ID tags the coders told them to use.
IIRC, building things from scratch was a PITA. But that could have
been my lack of experience with it too :-)
Chris
===
To: "Chris Winters" <chris@cwinters.com>, "Jeffrey W. Baker"
<jwbaker@acm.org>
From: "Perrin Harkins" <perrin@elem.com>
Subject: Re: Using DOM to build your output documents
Date: Thu, 4 Oct 2001 01:02:00 -0400
> * Jeffrey W. Baker (jwbaker@acm.org) [011003 19:52]:
> > I'd love to hear any other experiences with using the DOM to build
output
> > from scratch. I'd also like to hear people's opinions on XML::DOM (I
> > think it stinks and I've replaced it with a C DOM implementation).
>
> I can't speak to XML::DOM, but I used XMLC in Java to do this and
> there were aspects that were pretty nifty.
HTML_Tree is like XMLC, but less irritating, i.e. no lame compile cycle to
deal with and somewhat more straightforward. There's also an XML version
here: http://homepage.mac.com/pauljlucas/software/xml_tree/. I prefer a
more traditional templating approach, but some people love this stuff.
- Perrin
===
To: modperl@apache.org
From: Robin Berjon <robin@knowscape.com>
Subject: Re: Using DOM to build your output documents
Date: Thu, 4 Oct 2001 13:29:21 +0200
On Thursday 04 October 2001 01:43, Jeffrey W. Baker wrote:
> I believe that the canonical way to output a document using any web
> scripting language (Perl CGI, mod_perl, PHP, ASP, etc.) is to simply print
> out your markup, like this fictional example:
>
> while (my $row = $sth->fetchrow_arrayred()) {
> print "<tr><td>$row->[0]</td><td>$row->[1]</td></tr>\n";
> }
Yes, and I agree with you that this approach has severe drawbacks. Years of
practice have made it usable through templating systems and various tricks
that people discover as they learn. The linearity is one of the main problems
as if the beginning of your output is dependent on something farther down you
often have to resort to complex lookaheads. There are also problems with
coupling, in that code meant to process one data structure into a string will
often be able to process only that data structure. It's hard to make this
approach generic, or even to abstract large parts of it. And recursing into
arbitrarily deeply nested structures is up to you, whereas using the DOM with
XPath (or iterators), or XSLT takes care of that for you.
Another major advantage is pipeline processing. You can have several
processors in a row, all of them specialised and dealing with the same kind
of data structure (a DOM). This is similar to using filters, but filters are
painful and require reparsing at every stage. I find it much easier to use a
pipeline model, especially when I want to add a new feature as that new
feature will live on its own, separate from the rest of the code.
> I'd love to hear any other experiences with using the DOM to build output
> from scratch. I'd also like to hear people's opinions on XML::DOM (I
> think it stinks and I've replaced it with a C DOM implementation).
I gave up on XML::DOM the day I tried to patch it to make it DOM 2 compliant
(or even only to add namespace support). I tend to use SAX whenever I don't
need lookahead, and XML::LibXML for everything DOM related. It isn't 100%
complete but it's close, and will soon be. Watch perl-xml for an annoucement
of PerlDOM, as it seems likely to happen soon.
In all of my recent websites I've used combinations of DOM and SAX
processing, always with a pipeline approach. Most of the time this happens in
AxKit but there are exceptions where I decided to hand build a few things. I
also tend to make a growing use of XSP as it allows you to express the output
XML DOM you want from your code in quite a direct manner. As all
templating-like approaches you've got to be discplined for it to be readable,
but that's easy enough. And more importantly, writing taglibs (in order to
avoid embedded code) is rather trivial if you know SAX (and SAX is far from
being hard to learn).
==
To: Perrin Harkins <perrin@elem.com>
From: Chris Winters <chris@cwinters.com>
Subject: Re: Using DOM to build your output documents
Date: Thu, 4 Oct 2001 09:06:09 -0400
* Perrin Harkins (perrin@elem.com) [011004 01:03]:
> > * Jeffrey W. Baker (jwbaker@acm.org) [011003 19:52]:
> > > I'd love to hear any other experiences with using the DOM to build
> output
> > > from scratch. I'd also like to hear people's opinions on XML::DOM (I
> > > think it stinks and I've replaced it with a C DOM implementation).
> >
> > I can't speak to XML::DOM, but I used XMLC in Java to do this and
> > there were aspects that were pretty nifty.
>
> HTML_Tree is like XMLC, but less irritating, i.e. no lame compile cycle to
> deal with and somewhat more straightforward. There's also an XML version
> here: http://homepage.mac.com/pauljlucas/software/xml_tree/. I prefer a
> more traditional templating approach, but some people love this stuff.
Yeah, the compile cycle is irritating, but it allowed you to pick out
a particular node via a method without cycling through the whole tree
to find it. But I think XPath does the same sort of thing.
I prefer the templating approach as well -- I haven't run into many
instances where I needed to process something after it's already been
generated, although maybe having the capability would open my eyes to
such issues :-)
===