Re: Using DOM to build your output documents
On Wed, 3 Oct 2001, DeWitt Clinton wrote: > 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 whipped up a DOM from scratch that supports Document, DocumentFragment, Node, DOMImplementation, NodeList, and Element, then I wrapped some Perl around it. It is a lot less stressful when the W3C already specified the API for you :) -jwb
Re: Using DOM to build your output documents
* Perrin Harkins ([EMAIL PROTECTED]) [011004 01:03]: > > * Jeffrey W. Baker ([EMAIL PROTECTED]) [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 :-) Chris -- Chris Winters ([EMAIL PROTECTED]) Building enterprise-capable snack solutions since 1988.
Re: Using DOM to build your output documents
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 "$row->[0]$row->[1]\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). -- ___ Robin Berjon <[EMAIL PROTECTED]> -- CTO k n o w s c a p e : // venture knowledge agency www.knowscape.com --- "My girlfriend always laughs during sex, no matter what she's reading" -- Steve Jobs
Re: Using DOM to build your output documents
> * Jeffrey W. Baker ([EMAIL PROTECTED]) [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
Re: Using DOM to build your output documents
* Jeffrey W. Baker ([EMAIL PROTECTED]) [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 -- Chris Winters ([EMAIL PROTECTED]) Building enterprise-capable snack solutions since 1988.
Re: Using DOM to build your output documents
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
Using DOM to build your output documents
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 "$row->[0]$row->[1]\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