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

["Steve Comrie" <suppressed>]

> At this stage, I'm not committed to SSI, but it's more comfortable to
> me than writing bottom-up by transforming templates into presentation.
> I value others' impressions which have so far been offered.

Ed,

I'm sympathetic to your position. I just came off two projects where I used
C::A run-modes being called in a fashion similar to the SSI structure you're
describing.

There were occasions where I had 2 or more run-mode being called from a
single static HTML page to either the same or different C::A scripts. The
reasons behind this are mostly inconsequential, and generally not the way
that I'd code an application, but the situation called for it.

I did have run-modes in my system that produced output as simple: "2 items
in cart | 1,400 points | 2,600 points remaining" very much like your example
of output coming straight from cgi output wrapped inside <li> elements.

However, I also had run-modes in my system that output code as complicated
as this: http://www.unobserved.org/img/misc/essexample.gif. Not overly
complicated HTML-wise or structurally, but certainly more HTML then I would
want to have generated directly from my C::A code.

Conversely if each structural element of that screen were to be broken down
into bite-size cgi outputs that could be wrapped in a minimal amount of HTML
code, I still might be left with 1 cgi call for "Displaying 7-16 of 66
Rewards", 1 for the 6 products images and descriptions, and one for the Next
/ Previous / Page Jump functionality. And that's not even taking into
account for the fact that each of those run-modes would have to re-query the
database to calculate the values that it should output.

Most people on the list would agree that anything more (or less) than 1
template and 1 run-mode to achieve that screen-shot would be over (or under)
kill, but that's besides the point for right now.

By very definition, C::A provides you with a "Framework for building
reusable web-applications"

That means, that after I was finished my first of the two projects I
initially mentioned, and moved on to the second project (a duplicate of the
first with minor differences only in database content and visual layout). I
could use the exact same C::A modules I had created for the first project.
No code duplication, just new configuration files and templates.

When it came time to output that same screen shot for the second project,
the requirements had changed from a 3x2 layout with point value and product
name (as in project #1)  to a 1x6 layout with product name, point value &
extended description. All that had to change was a single template file for
that installation. No Perl code needed to be changed. Essentially, I'd just
cut out nearly all the development time from the second projects' budget.

In respect to your initial inquiry, everything that you propose to do is
possible using C::A and by using C::A as opposed to vanilla cgi scripts you
will probably see a decrease in development time. However, I think your
initial process list (1. Make it work,  2. Make it work right, 3. Make it
work fast) is missing 2 essential steps that really define the philosophy
behind using CGI::Application. Those steps are:

4) Make is easy to maintain / evolve
  and
5) Make it easy to reuse

Just as making changes to a CSS file is easier then making changes to an
HTML document, so is making changes to an HTML document easier than making
changes to a CGI script. By abstracting the presentation layer you make your
applications easier to maintain and easier to reuse at a later date.

Regardless of whether or you use Template::Toolkit or HTML::Template or roll
your own templating system, there is a A LOT to be said about using
templates in place of writing HTML code inside your cgi scripts. I know you
already understand those benefits because you're already using SSI files
instead of re-creating shared elements on every static HTML page.

If you want some assistance or code samples to move you along the path of
integrating templates with your C::A code, I and many other people on this
list would be willing to help, likewise with session handling, database
connections, form validation and more.

I didn't mean to ramble on so much, but I hope that I succeeded in giving
you a better impression of templates and how they can help you (in
combination with C::A) to make your work a little easier, more enjoyable and
hopefully a little more profitable :-)

---
Steve Comrie
- Please excuse the run-on sentences and typo's, I write more syntactically
correct Perl than I do english on most days :-)


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