You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Joachim Zobel <nc...@netcologne.de> on 2001/06/22 12:24:09 UTC
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
Posted by Wim Kerkhoff <wi...@merilus.com>.
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: wim@merilus.com
Re: SSI advocacy Was:: Multiple AddHandler statements
Posted by Robin Berjon <ro...@knowscape.com>.
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 <ro...@knowscape.com> -- 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
Posted by Perrin Harkins <pe...@elem.com>.
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
Posted by Joachim Zobel <nc...@netcologne.de>.
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
Re: SSI advocacy Was:: Multiple AddHandler statements
Posted by Perrin Harkins <pe...@elem.com>.
> 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