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

[Brett Sanger <suppressed>]

On Tue, Feb 22, 2005 at 02:13:04PM -0500, Halley, Edward D. wrote:
> 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

I don't want to engage in a "templates good/bad" debate, but I do want
to cover some of your points.

I'm coming in late here, but how do you pass parameters to an HTML page?

> 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.

I'm in favor of your method of "present data, and have the template
format it".  You're using CSS as the sole formatter, I'm using a
complete HTML page (incl CSS).

> Rather than writing code that produces presentations, I write
> presentations which include live components.  It's just a matter of
> perspective.

This sentence struck me, because that's exactly why I moved to
Template Toolkit away from HTML::Template.  I found I was modifying my
data in code to control how it would present, which destroys the point
of dividing presentation from code.  I switched to TT, and moved any
data restructuring the template didn't do to plugins.

I also HATE most of the TT example code, as it demonstrates all the ways
you can use TT to mingle code and presentation (in an attempt to
demonstrate the power of TT).  To me, the real power of TT lies in using
vmethods and plugins to move data manipulation out of the template AND
the originating code.  So my code simply reveals the data, my templates
say where to put what on the screen, and my plugins/vmethods make sure
the data is "pretty" for that given usage.  I NEVER make a database call
in a template, I never do much more than HTML::Template or other similar
"strict" templating languages would allow.  But the vmethods and plugins
called in the template ensure that my template is as neutral to the
structure of the incoming data as the code is to the template.

YMMV.

> 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.  ;)

I'm confused as to how you share data between SSI elements (I'm
not strong on SSI, I prefer to avoid any webserver dependency)  If you
can't, there would be one strong difference, if you can, ignore this :)

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


SSI does 1, I'm not sure it's a good solution for 2.  (see above) 

In my shop the designer is no programmer.  He doesn't really understand
the data I'm exporting any further than "list" or "hash" (and he doesn't
really get that last one).  But that lets him loop over that data and
tag it appropriately...be it by pure HTML, or CSS.  If you are the
designer AND the programmer, your needs may be different.

-- 
SwiftOne  /  Brett Sanger
suppressed   

---------------------------------------------------------------------
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