in reply to So, what *is* the best way to deliever dynamic content nowadays?
The short answer: yes. Some parts of our development want to be monolithic, and some don't. It's like Perl- some parts of Perl want to be OO, and some parts simply do not. mod_perl was a piece of this answer for our project (it's pretty monolithic) but it was too hard to make it spit out HTML all by itself. HTML::Mason pretty much solved that problem for us, and then we were left with the single remaining problem of how to represent the underlying data. Which is what your next two questions were about, so I'll stop at that for a minute.
To XML-ize or not?
This was an easy one for me, and I hope I can infect you with the zeal of the newly converted. If you can find a way to have your database do the things databases tend to be good at (e.g. indexing, search, etc.), and to keep XML around because it lets you have arbitrarily deeply nested data structures and other such niceties that Perl REALLY LIKES, this seems like an ideal solution to me.
After playing with an early version of Kwin Kramer's XML::Comma, I liked it so much that I tracked him down and took a solemn oath to forever uphold the honor of XML::Comma and to never use PHP again. Or something. It really is insanely cool. Check out this post or just read my short summary:
XML::Comma uses XML for two different purposes. First, it stores documents in untyped XML. Secondly, it uses a special flavor of XML to specify a single API for indexing (I'm using MySQL), storage (XML on the filesystem in my case), inverted indexing (MySQL again in my case), compression (GZip for me), Encryption (HMAC + symmetric key encryption here), and is capable of extending this interface to everything but washing your dirty undies.I highly recommend checking it out. I did. But be careful. I started out just playing with it in my spare time, and now it's become my full time job to play with it ;)
What this means for me is that when I use the Comma API to create a document a la:That last $doc->store() gives me (based upon my XML DocumentDefinition) a file on the filesystem that is gzipped, encrypted, HMAC'ed, sorted, and generally kept track of. It gives me corresponding fields in my database that are typed and indexed according to my specifications. It creates an inverted index for my search engine. And it does it many thousands of times every second even on my desktop machine, not to mention the quad Athlons we deploy on.my $doc=XML::Comma::Doc->new(type=>'Foo'); $doc->name()->first('David'); $doc->name()->last('Brunton'); $doc->phone()->area_code('509'); $doc->phone()->num('5551212'); $doc->store('main');
MySQL or Postgres?
I use Comma with MySQL. We've done some benchmarking of Postgres, but haven't figured out a good reason (performance or features) to switch yet. Besides, I think XML::Comma is still Postgres/MySQL agnostic, so barring the use of any of the arcane indexing stuff, I think I could probably switch without much effort.