[cgiapp] OT RE: [cgiapp] Inline C::A

["Dan Horne" <suppressed>]

We use a simple Perl-based CMS
(http://www.interactivetools.com/products/articlemanager/) which publishes
to static pages too. It used to write shtml files based on very simple html
templates, but I've switched to php so that I can include code that allows
me to do things with the output that can't be done with the CMS and SSI
alone. It's quite a nice compromise. The alternative is to go with a more
fully-featured CMS, but the users like the absolute simplcity of the current
one.

Dan

-----Original Message-----
From: Steve Comrie [mailto:suppressed 
Sent: Saturday, 8 January 2005 11:05 a.m.
To: Michael Peters
Cc: cgiapp
Subject: Re: [cgiapp] Inline C::A



> I might be missing something, but seems to me like you're just 
> reinventing SSI. Have you looked at mod_include ? It would be much 
> faster than having to bring php into the mix.

I guess in a way I have reinvented SSI, I didn't really think of that as I
was writing the code because I haven't used SSI in a very long time.

However, (as far as I know) SSI and PHP won't run together. I guess I don't
know whether or not my situation is unique, but here it is. We have used
C::A to build a CMS that publishes static html pages (often with some php
elements in it - I'll get to that a little bit later). Some aspects of a
static site that our CMS publishes (such as a shopping cart) tie back in to
the backend of our CMS (product database, customer tracking, order
management, etc). Therefore, it would be foolish for us to build the
front-end part of shopping cart in anything but C::A.

C::A is very strong (and my only choice) when it comes to building web
applications. That being said, not every site that we publish is (in and of
itself) an application. So often for minor aspects of a published site, our
CMS will output templates that contain php code.

I mentioned that there are often a lot of other little things that we do on
our sites that require php.

- Such as dynamic image create from TTF fonts for header images or buttons
on the fly.

- Simple one-off database column read or writes (many of our sites have
built in converstion tracking or personalization) for things that aren't
required to be wrapped in any additional logic. In cases like this, the
logic is in the C::A CMS backend of our software that generates the ROI
reports, or stores the entire visitor history, etc.

- Using PHP's transid ability to add the session id to the end of all links
in situations where we can't rely on cookies.

Many of these things could be handled in C::A or several simple perl
scripts, but we've decided to do it using php. I guess what I've created (is
a monster :P).

A PHP & Perl SSI clone. It allows (for better or worse) php and perl code in
the same page. *maybe* I'm the only person in the world with this particular
challenge (or brain damage to not come up with a pure perl solution). Please
use with caution :)


---
Steve Comrie


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




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