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
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
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
> 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
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 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: Multiple AddHandler statements
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
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: Multiple AddHandler statements
At 15:33 18.06.2001 -0700, you wrote: >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... > > > ... > AddHandler server-parsed .cgi > ... > > > > ServerName www.xyz.com > ... > AddHandler cgi-script .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). This is because you can not chain content handlers. One Option would be to use Apache::SSI. You can chain PerlHandlers. But isn't it possible to have one *.shtml, that includes both. This would IMHO be the much cleaner solution. The other way you probably end up using two different SSI implementations. Hth, Joachim -- "... ein Geschlecht erfinderischer Zwerge, die fuer alles gemietet werden koennen."- Bertolt Brecht - Leben des Galilei
Re: Multiple AddHandler statements
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 " - 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
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
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
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: Multiple AddHandler statements
Is there something in SSI which cant be done in a better way using Perl ??
Re: Multiple AddHandler statements
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 !
Multiple AddHandler statements
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... ... AddHandler server-parsed .cgi ... ServerName www.xyz.com ... AddHandler cgi-script .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). Any help would be greatly appreciated.
