Mailing List Archive

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 process, not an event. T::T also allows
you to embed logic in the templates, so let the programmer beware.

T::T also works terrific with mod_perl, which is useful if your apps are
database-intensive. mod_perl also has other capabilities to allow you to
move away from the CGI module. libapreq/Apache::Request

--
Read my Latest Blog Post: Historical Forecasts for Your BTS Project Tracker
<https://bangkokbeachtelecom.com/add-historical-forecasts-to-your-project-tracker/>
Russell Lundberg - sent from my iPhone
Bangkok, Thailand +66 91 546 4539
https://bangkokbeachtelecom.com/
LinkedIn Profile <https://th.linkedin.com/in/russelllundberg>

On Mon, Nov 27, 2017 at 11:25 AM, Igor Chudov <ichudov@gmail.com> wrote:

> 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 a great idea. It was not.
>
> About two years later, I realized that use of "perl inside HTML" is
> completely unsuitable for the complex things that I was doing, and I
> abandoned Embperl and switched to the CGI module. The CGI module uses "HTML
> generation from perl" and that was much more suitable for me for two
> reasons. One reason is that my web apps are heavy with logic and relatively
> light with HTML. The other reason is that I like to separate presentation
> from application logic, and using perl in proper manner made that easy to
> accomplish.
>
> Fast forward to today, I can see that CGI module is being deprecated!
>
> The alternatives to it, suggested by CGI::Alternatives, seem to force on
> me a different paradigm of development. For example, HTML template seems to
> be a rerun of Embperl. That gives me bad heartburn.
>
> Several other frameworks are completely different functionally, in ways
> that seem to be not very compatible with my thinking.
>
> Anyway, I am sort of open minded to not use perl CGI module for HTML
> generation. Now what?
>
> Is there a HTML generation perl module that does not force me to use
> "different paradigms", but that simply makes outputting HTML from perl an
> easy and maintainable task?
>
> Thanks a lot. I am not looking to start a flamewar. I hope that I did not
> insult anyone. If I did, I apologize. All I want it to find a way to
> generate HTML without switching to completely new, or discarded like
> Embperl, paradigmatic choices. Thanks a lot.
>

>>>>> "Russell" == Russell Lundberg <lundberg.russell@gmail.com> 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::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,";

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/Dart consulting, Technical writing, Comedy, etc. etc.
Still trying to think of something clever for the fourth line of this .sig

"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,";
>

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 CGI. I haven't verified the speed or size claims but it's
working well on an old Raspberry-Pi (very low volumes) so can't be too bad.

It claims to be 100% compatible on the parsing side with all the html
stuff removed. I haven't pushed very hard to verify this.

Brian


On 30/11/17 8:27 am, 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,";
>>
>

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,";
>>
>