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 built-in
support for mod_perl and mod_perl2 as well as FastCGI.
It has the benefit of having developed and refined over 20 years with input from dozens of
contributors and being deployed on thousands of websites. "
In other words : "don't panic !".
It is not because it is no longer included in the core perl distribution, that it will
cease to be available, or stop working, anytime soon. I am quite sure that the current
maintainer does not want to end up changing his name and moving to some desert island
where WiFi comes by boat once a month.
Second : the part of it that will apparently not be so assiduously maintained anymore, is
the part which generates (simple) HTML directly as output.
And this is understandable, considering that nowadays HTML is getting increasingly
"sophisticated" in terms of styles, graphics, animations, adaptability to multiple sorts
and sizes of rendering devices, etc. It would be a nightmare for any code maintainer, to
try to keep abreast of this evolution and provide meaningful interaction with it from
within the CGI module.
Third : if you are the sole developer and maintainer of a web application, it does not
really matter if the logic and/or presentation of your application is located more in the
programs or more in the "pages". The important part is that /you/ know where it is and
can still find it 6 months later. And it may even help in such a case, to have everything
in one place, instead of having to figure out where the code really is, which generates
this ugly-looking value in row 7 of the table that the user sees.
Where it starts to get more tricky, is when several people have to work on the
application, and/or when you want to "sub-contract" the logic part or the graphic part to
someone else.
All in all, based on my own experience (which includes many years, many websites, many
applications and many perl cgi-bin scripts using CGI), for someone who has been until now
using CGI to both parse submit requests and to generate HTML output, and who wants to
gradually move on and, in a first step, just avoid the HTML-generating part, I would
recommend the following approach :
- continue to use CGI to parse the submit parameters, and keep the "business logic" in the
script, where it is now.
- have a look at Template::Toolkit in terms of creating the HTML output pages
separately
- in your script, instead of using calls to generate HTML piece by piece, build a perl
structure containing the values which you want to display, and pass them on, as a hash, to
Template::Toolkit along with the name of the HTML "template" page which you created. Then
in the template, you can just "pull" the values out of this hash, where you need them to
be displayed.
It is really quite easy, once you get the hang of it, and it does not take long to get
that hang.
Maybe the easiest way to start trying this, is to run your current application from a web
browser, and "save as html" the page that you see.
Then edit that saved HTML page, and everywhere that there is some dynamic value displayed
(that comes from your script's logic), replace it by a "placeholder" like
[% var1 %], [% var2 %].
Then in your script, essentially,
1) you create a hash ($hashref), and store your data in it, under keys like "var1", "var2"
etc..
1) you create a new "Template object" (only once), say $TT
2) you call $TT->process($hashref,$template_file)
This tells Template::Toolkit to read the file $template_file, and to replace each "marker"
that it finds there, by the corresponding value of the key in your $hashref.
(So for example : [% var1 %] will "pull" $hashref->{'var1'} and insert it here instead of
the "[% var1 %]" marker.)
Et voila ! logic vs display separation in a nutshell.
Now you are free in your script from
print $cgi->h1($title);
and replace it by
$hashref->{title} = $title;
... (put many more things in $hashref)
...
$TT->process($hashref,$template_file); # (replaces : print $cgi->end_html;)
and in your "html template" $template_file, you put
<h1 id="myh1" class="something"..>[% title %]</h1>
and then you can give the $template_file file, to some graphic guru to make it look
better, without having to change your script anymore. You just have to tell the guy not to
touch anything between [% .. %].
There are many other ways to do it. But Template::Toolkit is simple, basic, and
understandable without having to absorb first any metaphysical concept about the universe
and everything. And it can of course do many more things than the simple example above,
but you'll learn these as you go, and as you need; and you can choose yourself which parts
you keep in the scripts, and which parts you sub-contract elsewhere.
On 29.11.2017 22:27, Michael A. Capone wrote:
"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, and I only use
CGI.pm to get
the request parameters (but I use it a LOT). Is there another modeule that I
can drop in
to get that functionality? Or should I happily keep using CGI.pm (which I have
no problem
installing from CPAN as long as it's available).
On 11/29/2017 01:13 PM, Randal L. Schwartz wrote:
My CGI::Prototype is still in use by one of my primary clients, and uses
the CGI module only for parsing the incoming request. The rest is a
nice prototype-inheritance structure of Template Toolkit objects.
print "Just another Perl hacker,";
