Re: Multiple AddHandler statements

[Pierre-Yves BONNETAIN <bo...@acm.org>]

   Hi Douglas,

> We have a CGI script which dynamically generates a certain page on our site.
> We want to include an SSI on that dynamically created page.  Is that
> possible?  We have two "AddHandler" statements for files that end in .cgi...
> 
> Unfortunately, the dynamically generated page is not being server-parsed
> because the Include virtual statement is showing up in the HTML source (the
> same statment on a .shtml file, however, is replaced with the result of the
> SSI).
> 

   We've been doing quite the same thing on our server. Our way out (maybe not
the best one; I'm waiting for the list's answers :-) is to generate the dynamic
page (step one, which you're obviously doing) and then, at the end of this phase
of the request, generate an internal redirect to the newly created page.
   This way, Apache processes the dynamic/SSI page, just as if it were
requested by the user.
   Maybe that's a little heavy (but it's still better than sending an external
redirect to the user's browser !)
   Hth,
-- Pierre-Yves Bonnetain - CTO - http://www.rouge-blanc.com
   Fastest wines in Europe !

Re: Multiple AddHandler statements

[Peter Reif <ga...@adv.magwien.gv.at>]

Mithun Bhattacharya *EXTERN* wrote:
> 
> No offense meant but it is my personal opinion that SSI can mess up a
> system worse than Perl ever could. Also the person who had initiated
> this thread was using SSI to execute a third party application. I am not
> sure why a system command would be worse than doing a SSI.
> 
That's right. I use it only with option "IncludesNOEXEC", and I would
never write any complex application with SSI.

Peter

Re: Multiple AddHandler statements

[Mithun Bhattacharya <mi...@egurucool.com>]

Right now I wont say that the idea of SSI is bad its just that the usual
SSI implementations that I come accross are usually when I see them
going wrong. The most common example is of that of including content for
banners. I dont know whether it is a configuration goofup or something
else but I have noticed quite a few times the application aborting and
then the abort message turning up instead of the banner. If that person
was doing a system call I am assuming he would have read it some where
in a book or by perldoc - in any case it is well documented to trap
errors. In my opinion I would have a rather well informed user putting
HTML and other applications on my server than assume ignorance on their
part.

I have even seen users including HTML content by doing a "cat
<filename>" - bad practice but then I could always claim my users dont
know any better cant I.

Another thing isnt SSI supposed to be slow for almost everything other
than very rudimentary fucntions and that 

Finally SSI can be almost as good a replacement for rudimentary CGI and
some templating work but I feel in the long run it is better to put a
proper script or a template mechanism in place rather than sticking to
SSI. Atleast I would rather make the effort to give a alternative
solution to SSI.



Mithun

Re: Multiple AddHandler statements

[Ged Haywood <ge...@www2.jubileegroup.co.uk>]

Hi there,

On Fri, 22 Jun 2001, Mithun Bhattacharya wrote:

> No offense meant but it is my personal opinion that SSI can mess up a
> system worse than Perl ever could.

Would you care to elaborate?

73,
Ged.

Re: Multiple AddHandler statements

[Mithun Bhattacharya <mi...@egurucool.com>]

No offense meant but it is my personal opinion that SSI can mess up a
system worse than Perl ever could. Also the person who had initiated
this thread was using SSI to execute a third party application. I am not
sure why a system command would be worse than doing a SSI.


Mithun

Re: Multiple AddHandler statements

[Peter Reif <ga...@adv.magwien.gv.at>]

Mithun Bhattacharya *EXTERN* wrote:
> 
> Is there something in SSI which cant be done in a better way using Perl
> ??

Yes, giving authors a simple tool with which they can't mess around.
Perl is too powerful.

Peter

Re: SSI advocacy Was:: Multiple AddHandler statements

[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

[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

[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

[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

[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

SSI advocacy Was:: Multiple AddHandler statements

[Joachim Zobel <nc...@netcologne.de>]

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: Multiple AddHandler statements

[Mithun Bhattacharya <mi...@egurucool.com>]

Is there something in SSI which cant be done in a better way using Perl
??