Re: SSI advocacy Was:: Multiple AddHandler statements
Joachim Zobel wrote: Including If-Modified-Since - 304 responding? No, none of them handle that (well, AxKit?), probably because most sites need to do more than stat-ing the template files to determine if the page content has been modified. A site with no dynamic content could be pre-generated with a make-like procedure and served statically. In fact my main objection to the majority of templating systems is that they are frameworks. I am using a homegrown template engine at the moment and probably would be using template toolkit if I started now, but I definitely hate to be framed at work:) Template Toolkit, Text::Template, and HTML::Template are all pretty good at staying out of your way. They're not frameworks like Mason and Embperl. But hey, if you like SSI then go ahead and use it. It's good at what it does. I was just pointing out that the templating tools are pretty solid as well. - Perrin
Re: SSI advocacy Was:: Multiple AddHandler statements
On Sunday 24 June 2001 11:55, Perrin Harkins wrote: Joachim Zobel wrote: Including If-Modified-Since - 304 responding? No, none of them handle that (well, AxKit?), probably because most sites need to do more than stat-ing the template files to determine if the page content has been modified. Yes, AxKit will send 304s properly for anything that can be cached. Adding your own caching (according to whatever rules you want) is easy. That's a big performance boost imho if you have a way to tell whether your content has changed or not. -- ___ Robin Berjon [EMAIL PROTECTED] -- CTO k n o w s c a p e : // venture knowledge agency www.knowscape.com --- It's better to be quotable than to be honest. -- Tom Stoppard
Re: SSI advocacy Was:: Multiple AddHandler statements
At 12:35 22.06.2001 -0400, you wrote: 1. SSI with XBitHack full plays the 304 game for me. Every time the catalog database is updated, its SSI frame gets a touch. Thats it. Simple. Efficient. Most of the perl templating systems would be just as good on these points, Including If-Modified-Since - 304 responding? In fact my main objection to the majority of templating systems is that they are frameworks. I am using a homegrown template engine at the moment and probably would be using template toolkit if I started now, but I definitely hate to be framed at work:) Another point for SSI is that lots of people understand them. Joachim -- ... ein Geschlecht erfinderischer Zwerge, die fuer alles gemietet werden koennen.- Bertolt Brecht - Leben des Galilei
SSI advocacy Was:: Multiple AddHandler statements
At 14:33 19.06.2001 +0530, you wrote: Is there something in SSI which cant be done in a better way using Perl ?? Yes. 1. SSI with XBitHack full plays the 304 game for me. Every time the catalog database is updated, its SSI frame gets a touch. Thats it. Simple. Efficient. 2. SSI provides a way to modularize static HTML. I have lots of small HTML snippets. Many of them are generated by a content manager. These snippets are put together using SSI. 3. Performance. The main drawback of using SSI is that you mess up error handling. If an included script generates an error, the 200 has already been sent. This is the price I have to pay for the fact, that normally while the script is still running, the browser is already displaying the pages header table. Joachim -- ... ein Geschlecht erfinderischer Zwerge, die fuer alles gemietet werden koennen.- Bertolt Brecht - Leben des Galilei
Re: SSI advocacy Was:: Multiple AddHandler statements
Joachim Zobel wrote: At 14:33 19.06.2001 +0530, you wrote: Is there something in SSI which cant be done in a better way using Perl ?? Yes. 1. SSI with XBitHack full plays the 304 game for me. Every time the catalog database is updated, its SSI frame gets a touch. Thats it. Simple. Efficient. 2. SSI provides a way to modularize static HTML. I have lots of small HTML snippets. Many of them are generated by a content manager. These snippets are put together using SSI. 3. Performance. The main drawback of using SSI is that you mess up error handling. If an included script generates an error, the 200 has already been sent. This is the price I have to pay for the fact, that normally while the script is still running, the browser is already displaying the pages header table. Joachim Exactly. Most of our site is done using SSI's. However we are in the process of moving to EmbperlObject [1], so that more HTML can be reused, inheritance can be done, and our developers can spatter bits of code here and there if required quite easily. By adding one line of [! !] code to the top of the content of the page, they can override the default things in the title and the header of the page (which is a different object). We are really loving HTML::EmbperlObject and HTML::Embperl. It makes for a cleaner way of modularizing static HTML, integrating dynamically generated HTML, provide error handling, and tap into the power and speed of mod_perl. Give it a try. Give it a try... it is worth it, and won't require a lot of work to migrate to it. [1] http://perl.apache.org/embperl [2] http://take23.org/articles/2001/02/07/embperlobject.xml -- Regards, Wim Kerkhoff, Software Engineer Merilus, Inc. -|- http://www.merilus.com Email: [EMAIL PROTECTED]
Re: SSI advocacy Was:: Multiple AddHandler statements
At 14:33 19.06.2001 +0530, you wrote: Is there something in SSI which cant be done in a better way using Perl ?? Yes. 1. SSI with XBitHack full plays the 304 game for me. Every time the catalog database is updated, its SSI frame gets a touch. Thats it. Simple. Efficient. 2. SSI provides a way to modularize static HTML. I have lots of small HTML snippets. Many of them are generated by a content manager. These snippets are put together using SSI. 3. Performance. Most of the perl templating systems would be just as good on these points, and would allow you to catch errors if you are willing to wait until the whole document is generated before sending. They also perform about the same, with Apache::SSI actually beating mod_include in my benchmarks. However, SSI has one thing going for it, and that's memory usage. It doesn't cache pages in memory (neither the C or Perl version), so it doesn't grow as it processes new pages. (Well, it grows to the size of the biggest single page processed.) This means you can use it on a site with thousands of unique pages and not worry that all of them will end up cached in memory for each mod_perl process. I think the original question on this thread was how to post-process CGI output through SSI. I've done this using Apache::SSI, just collecting my output in a string and then feeding it to Apache::SSI, which provides a method you can call for this. You could also look at CGI::SSI_Parser, which I have not used. - Perrin
