RE: [cgiapp] Using CGI::Application and SHTML/SSI pages?

["Halley, Edward D." <suppressed>]

Halley, Edward D. wrote:
> Thanks for the tips-- I'll look at Template Toolkit but I'm not
> particularly fond of templates; it feels like the tail wagging the dog.

Michael Peters wrote:
> Really? I'm *so* glad that there are good templating solutions out 
> there. Separating the content from the code is a godsend.

That's what CSS and the wrapping HTML are for.  That's why an HTML
file which calls on one or more CGIs to render small, simply-
formatted lists is preferable (unless the server can't cope).  In my
CSS, I can say that any <LI> inside a given <SPAN CLASS="foo">
appears in a given style.  Then all my CGI must print is <LI>item 1
<LI>item 2 ...  The CGI needs to know no style, no formatting,
nothing but a bare <LI>.  It can get more complicated, but not much.

A lot of developers think of the code first and the stuff that must
wrap it second.  That's fine, but I prefer to think of the user's
goals first, and the code that makes it possible will support that.
Rather than writing code that produces presentations, I write
presentations which include live components.  It's just a matter of
perspective.

Michael Peters wrote:
> Besides, don't you consider using an HTML page with SSI to be a 
> template? If that's all you are doing, then it's pretty much 
> HTML::Template with a different syntax.

You reinforce my argument that the approaches have no inherent
benefits, besides which end of the problem you consider to be the tail
and which end of the problem you consider to be the dog.  ;)

Michael Peters wrote:
> This is really a downside of using SSI like that for multiple CGI's.
> If you are using vanilla cgi (not mod_perl) then your server will not
> only have to spawn a perl process for each request, but multiple perl
> processes per request and that can really slow things down.

Process:
   1:  Make it work.
   2:  Make it work right.
   3:  Make it work fast.

For personal use during development, I don't mind it being "slow."  If
mod_perl is the key to making multiple CGI blurbs work well on a single
page, then I'll be happy to ensure that mod_perl is in use on the
production server.  If even mod_perl can't save me, I need to look at
some sort of "meta-modes" scheme to conglomerate multiple panes on the
same page without incurring DB connection limits. 

[ e d  h a l l e y ]----------------------------------------------------

---------------------------------------------------------------------
Web Archive:  http://www.mail-archive.com/suppressed/
              http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: suppressed
For additional commands, e-mail: suppressed