Hi.
To contribute my 0.02€ to the matter :
First of all, I believe that it is worth re-reading
https://metacpan.org/pod/distribution/CGI/lib/CGI.pod#DESCRIPTION
and pondering what it really says. For example this :
"CGI.pm performs very well in a vanilla CGI.pm environment and also comes with
I've just put a system together with CGI::Simple and everything seemed
to behave properly. I seem to recall other CGI.pm compatible things out
there as well when I was looking around. CGI::Simple seems to be working
well enough that at some point I might go back and tweak some old stuff
that uses C
"and uses the CGI module only for parsing the incoming request."
I was going to follow up on this thread and ask for suggestions on what
I could/should use for incoming request parsing. I have never gone
further in mod_perl beyond Apache::Registry and just running traditional
CGI programs, an
> "Russell" == Russell Lundberg writes:
Russell> T::T also works terrific with mod_perl, which is useful if your
Russell> apps are database-intensive. mod_perl also has other
Russell> capabilities to allow you to move away from the CGI module.
Russell> libapreq/Apache::Request
My CGI::Proto
I suggest Template::Toolkit (
http://search.cpan.org/~abw/Template-Toolkit-2.27/) Most of my web apps
are also relatively light on HTML, for which T::T works great. And to your
well-founded concern, T::T makes it pretty easy to keep separate logic and
presentation.
Although keep in mind that is a
I am a very long term user of the famous CGI module. My biggest project is
www.algebra.com. There are al;so many others.
Let me mention that my use of perl on the web, a very long time ago,
started out with Embperl.
At that time, I thought that use of HTML templates with perl code sprinkled
in is
