On Tue, 22 Feb 2005 14:13:04 -0500, Halley, Edward D.
<suppressed> wrote:
>
> 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.
This is no different from using templates. I prefer to keep all the
HTML in the same place (the templates) regardless of whether it is
styled using CSS or directly in the HTML. Your approach would put
some of the HTML in SSI files, and some of the HTML in your CGI
scripts. Regardless of how simple the HTML in your CGI scripts is, it
still splits things up. Also, you limit what the desingers can do
with the layout (unless you are also the designer). If your code
provides a list of <LI> items, but the designer wants to put the data
into 3 columns, can that still be done with CSS? (I'm not a CSS
expert, so I'm not sure about that one)
> 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.
I generally try to get my designers to present me with a static site
that does what they want. Then I fill in the dynamic bits wherever
they need to go. When doing a project for a customer, I can get a
signoff on the functionality and look of the application before a
single line of code is written (I've found most clients care more
about the look then the code anyway).
> 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. ;)
Agreed, they can be very similar for the functionality you are after.
> 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.
Agreed again. However, you really haven't given a good reason for not
using templates. You just prefer to use the SSI method.
However, we are moving very far away from your initial question, and
moving into an area where you are not having any problems :) So I'll
stop here, and respond to your initial question in another post to
keep the threads clean.
Cheers,
Cees
---------------------------------------------------------------------
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
Mail converted by mhonarc 2.6.15
This archive provided courtesy of JSW4.NET, Internet Hosting Services for Small Business.