[32798] in Perl-Users-Digest
Perl-Users Digest, Issue: 4062 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Oct 23 21:09:39 2013
Date: Wed, 23 Oct 2013 18:09:07 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Wed, 23 Oct 2013 Volume: 11 Number: 4062
Today's topics:
Replacement for CGI.pm <bernie@fantasyfarm.com>
Re: Replacement for CGI.pm <marius@ieval.ro>
Re: Replacement for CGI.pm <peter@makholm.net>
Re: Replacement for CGI.pm <rweikusat@mobileactivedefense.com>
Re: Replacement for CGI.pm <ben@morrow.me.uk>
Re: Replacement for CGI.pm <snob@pense-mainz.eu>
Re: Replacement for CGI.pm <rweikusat@mobileactivedefense.com>
Re: Replacement for CGI.pm <ben@morrow.me.uk>
Re: Replacement for CGI.pm <john@castleamber.com>
Re: Replacement for CGI.pm <xhoster@gmail.com>
Re: Replacement for CGI.pm <rweikusat@mobileactivedefense.com>
Re: Replacement for CGI.pm <gravitalsun@hotmail.foo>
Re: Replacement for CGI.pm <ben@morrow.me.uk>
Re: using File::Spec to figure out that Path::Class is <cal@example.invalid>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Tue, 22 Oct 2013 09:51:47 -0400
From: Bernie Cosell <bernie@fantasyfarm.com>
Subject: Replacement for CGI.pm
Message-Id: <fh0d69dodof0i5ie3phhpv7utllfkb2bv7@library.airnews.net>
CGI.pm is very old and I gather that its use is deprecated. Is there a
better/newer package for handling the CGI interface between Perl and the
web server? We use it both ways: to parse the incoming variables [and
cookies] and to generate the outgoing HTML. Our needs are pretty simple:
just those two functions. It seems to work, and we really haven't had any
trouble, but see more and more reports that one should *never* use
CGI.pm... And so : if not, what to use instead? THANKS!!
/Bernie\
--
Bernie Cosell Fantasy Farm Fibers
bernie@fantasyfarm.com Pearisburg, VA
--> Too many people, too few sheep <--
------------------------------
Date: Tue, 22 Oct 2013 17:08:01 +0300
From: Marius Gavrilescu <marius@ieval.ro>
Subject: Re: Replacement for CGI.pm
Message-Id: <87iowptn3y.fsf@ieval.ro>
--=-=-=
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable
Bernie Cosell <bernie@fantasyfarm.com> writes:
> CGI.pm is very old and I gather that its use is deprecated. Is there a
> better/newer package for handling the CGI interface between Perl and the
> web server? We use it both ways: to parse the incoming variables [and
> cookies] and to generate the outgoing HTML. Our needs are pretty simple:
> just those two functions. It seems to work, and we really haven't had any
> trouble, but see more and more reports that one should *never* use
> CGI.pm... And so : if not, what to use instead? THANKS!!
>
> /Bernie\
If what you have works and you don't intend to change it, then there is
no reason to replace CGI.pm with something else.
Otherwise, CGI.pm is still good for parsing incoming variables. However,
you should use a template system for generating HTML. I personally use
HTML::Template::Compiled, but Template::Toolkit seems to be the most
used/best one.
=2D-=20
Marius Gavrilescu
--=-=-=
Content-Type: application/pgp-signature
-----BEGIN xxx SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)
iQIcBAEBCgAGBQJSZobUAAoJEMoENb5ewbNitggP/iGxRz1mIsfwSRNcLgJaxIk1
8cLGxLXbofUtH0/d6nsH3/pylZcoGmOPbaUERzF3MqOT6FaOWVq5G7fheFaLQmvG
S2WgJ9R5Gl98sdWcuS9cI1521R+1N075u+ZfMHK69W3y3QDDDrUG31uRDOBLGxj3
lFC2cW54BF/EKSK23Bha5BFI8P07/5Z5DYzuRj2LzHe3f8Dcvn7HtPYvSgJE5c26
C38oP66mQQVNtkEWwBbAUoWXTQiHQ0pQA+VmOVOu74X1KO3So7PHodu0zn5ZX8D5
gh6USsaIpRGiYyqcNQUhuS33h0Pdnid1dGtxiip+EjWe/WW3OB/+EQwrsjZnvMXS
n1Ji2shwIrumlDyadeToq7ewwDMQmgZ3nKlWIcbJr1jmY+5JTf8EDEiv1tGCx81P
PlrP+CwQ+O0myrNCGrQXsXZNMa3KcRORUO6gNOeY66tVX8+mnU8jJbhZPTEpgfoA
ur5TyJjWUaP9K2YzkiAu6IBQqHFCsPp9JsecM89Yjxji6zsOxl87wyaOf1YhcJTu
67TCtD//jk7PZDKgK37/kMrcufHF2e30CdrJLGgsXyC48brkHYKJ3rkXlWPXP4c9
wAKNiRoM7QHLmq1jQMcAt+S4aax339dMElZVHhJTO9QnKSbuFx0c6lnJyr50hoEL
6fBnKYWbOJnX5Ri3Muz9
=liwd
-----END PGP SIGNATURE-----
--=-=-=--
------------------------------
Date: Tue, 22 Oct 2013 16:12:03 +0200
From: Peter Makholm <peter@makholm.net>
Subject: Re: Replacement for CGI.pm
Message-Id: <87zjq1z970.fsf@vps1.hacking.dk>
Bernie Cosell <bernie@fantasyfarm.com> writes:
> CGI.pm is very old and I gather that its use is deprecated. Is there a
> better/newer package for handling the CGI interface between Perl and the
> web server? We use it both ways: to parse the incoming variables [and
> cookies] and to generate the outgoing HTML.
I would replace the non-HTML parts of CGI.pm with Plack.
Using the CGI handler it is easy to produce CGI scripts and it is easy
to later "upgrade" to something persistent.
Using Plack::Request and Plack::Response you get almost the same
internal features than the request handling parts of CGI.mp. At least
easy access to request parameters and cookie handling.
It been years since I have used the HTML-parts of CGI.pm. Most of the
time I would use a real template system (Template::Toolkit) and write
the HTML by hand.
For an API comparable to CGI.pm's HTML interface I think HTML::Tiny can
be used instead.
//Makholm
------------------------------
Date: Tue, 22 Oct 2013 15:20:40 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Replacement for CGI.pm
Message-Id: <87hac9s7yf.fsf@sable.mobileactivedefense.com>
Bernie Cosell <bernie@fantasyfarm.com> writes:
> CGI.pm is very old and I gather that its use is deprecated. Is there a
> better/newer package for handling the CGI interface between Perl and the
> web server? We use it both ways: to parse the incoming variables [and
> cookies] and to generate the outgoing HTML. Our needs are pretty simple:
> just those two functions. It seems to work, and we really haven't had any
> trouble, but see more and more reports that one should *never* use
> CGI.pm...
As of now (perl 5.18.0), CGI.pm has neither been removed from the perl
core nor is listed in the 'future deprecations' section. AFAICT, there's
a bunch of marketing clowns^W^Wweb devsloppers who strongly market their
opinion that it ought to be removed - with the fact that "Oh my fancy
darling!" uselessnesses a la Mo "my antlers are bigger than yours!" ose
being all but unusuable in CGI programs certainly being a mere
coincidence - but so far, that's it.
I'm using it, not because it is anything in particular, just because it
is available and works (within its limits). If you want something
specific (eg, HTML-generation via templates), I suggest that you look
for a module providing what you want to have. For as long as CGI.pm does
what you need, there's seems to be little reason to stop using it:
Customers generally don't care about what developers consider
fashionable today.
------------------------------
Date: Tue, 22 Oct 2013 15:40:40 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Replacement for CGI.pm
Message-Id: <8cfija-lun.ln1@anubis.morrow.me.uk>
Quoth Bernie Cosell <bernie@fantasyfarm.com>:
> CGI.pm is very old and I gather that its use is deprecated.
I don't think it's deprecated, as such; there are just newer and simpler
modules for doing the same job.
CGI itself, however, probably should be considered obsolescent. Running
a persistent application process which communicates with the web server
via FastCGI or proxied HTTP generally scales better, and often allows a
better code structure. (Note that CGI.pm supports both FastCGI and
mod_perl.)
> Is there a
> better/newer package for handling the CGI interface between Perl and the
> web server? We use it both ways: to parse the incoming variables [and
> cookies] and to generate the outgoing HTML. Our needs are pretty simple:
> just those two functions. It seems to work, and we really haven't had any
> trouble, but see more and more reports that one should *never* use
> CGI.pm... And so : if not, what to use instead? THANKS!!
As far as parsing incoming requests goes, nowadays it would be foolish
to use anything which isn't based on Plack. Plack is a generic
web-server-interface module; it allows you to switch from a CGI backend
to FastCGI/HTTP/mod_perl/whatever without changing anything else in your
code. Plack::Handler::CGI is the CGI interface; the documentation for
that module explains how to create a CGI script that invokes your
application properly.
Plack itself provides a rather low-level interface to incoming requests
(the interface is called PSGI, and is designed to be as simple as
possible). It also provides Plack::Request, a slightly higher-level
interface; if you're used to using CGI.pm, a Plack::Request looks very
much like a CGI request object, so you can probably stick with that.
There are also a number of frameworks which layer on top of Plack to
provide more sophisticated facilities, such as mapping incoming requests
to methods on objects and managing database connections and sessions and
so on.
As far as output goes, I would recommend using Template.pm, either
directly or through one of the frameworks which supports it. It takes a
very different approach from CGI.pm: rather than calling methods which
generate HTML, you write HTML templates (generally in their own files)
which you can then fill in with values from your program. If you'd
rather stick to a CGIish interface, I'm sure there are modules on CPAN
which will do that; a quick look finds HTML::Stream, which looks pretty
decent.
Ben
------------------------------
Date: Tue, 22 Oct 2013 17:51:31 +0200
From: Joachim Pense <snob@pense-mainz.eu>
Subject: Re: Replacement for CGI.pm
Message-Id: <bcnl83Fj6b3U1@mid.individual.net>
Am 22.10.2013 16:08, schrieb Marius Gavrilescu:
>
> Otherwise, CGI.pm is still good for parsing incoming variables. However,
> you should use a template system for generating HTML. I personally use
> HTML::Template::Compiled, but Template::Toolkit seems to be the most
> used/best one.
>
I feel that writing HTML using CGI.pm with its factoring possibilities
is far more elegant than using templates; I use it even for static web
pages. The goal is never use any of < and > when writing HTML.
Joachim
------------------------------
Date: Tue, 22 Oct 2013 17:02:26 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Replacement for CGI.pm
Message-Id: <878uxls38t.fsf@sable.mobileactivedefense.com>
Joachim Pense <snob@pense-mainz.eu> writes:
> Am 22.10.2013 16:08, schrieb Marius Gavrilescu:
>>
>> Otherwise, CGI.pm is still good for parsing incoming variables. However,
>> you should use a template system for generating HTML. I personally use
>> HTML::Template::Compiled, but Template::Toolkit seems to be the most
>> used/best one.
>>
>
> I feel that writing HTML using CGI.pm with its factoring possibilities
> is far more elegant than using templates; I use it even for static web
> pages. The goal is never use any of < and > when writing HTML.
I'd like to second that, at least to a degree: Especially when building
user interfaces, the abstraction, conditional execution and repetition
facilities of a 'real' programming language enable working with form
elements at a much higher level than HTML or 'some templating languages
based on html'[*] usually do. Eg, this is a (partial) real-world example
of code creating a form:
sub form()
{
return ($cgi->start_form(-action => 'vmecs-create.cgi'),
$cgi->table(7, #{ border => 1 },
$cgi->t_r(menu('company')),
$cgi->empty_line(),
two_params(['name', 20, MAX_DNS_LABEL],
['dns_domain', 40, MAX_DNS_NAME]),
$cgi->empty_line(),
two_params(['ipv4_addr', MAX_DOTTED_QUAD],
['netmask', MAX_DOTTED_QUAD]),
$cgi->flush_right(3,
param('gate', MAX_DOTTED_QUAD)),
$cgi->empty_line(),
two_params(['pool_net', MAX_DOTTED_QUAD],
['pool_mask', MAX_DOTTED_QUAD]),
$cgi->flush_right(3,
param('pool_size', MAX_U32)),
[...]
[*] The only template-system I'm somewhat familiar with is JSF/
RichFaces.
------------------------------
Date: Tue, 22 Oct 2013 17:49:50 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Replacement for CGI.pm
Message-Id: <eumija-5vq.ln1@anubis.morrow.me.uk>
Quoth Rainer Weikusat <rweikusat@mobileactivedefense.com>:
> Joachim Pense <snob@pense-mainz.eu> writes:
> >
> > I feel that writing HTML using CGI.pm with its factoring possibilities
> > is far more elegant than using templates; I use it even for static web
> > pages. The goal is never use any of < and > when writing HTML.
>
> I'd like to second that, at least to a degree: Especially when building
> user interfaces, the abstraction, conditional execution and repetition
> facilities of a 'real' programming language enable working with form
> elements at a much higher level than HTML or 'some templating languages
> based on html'[*] usually do.
TT2 allows all those things, with the advantage of not being Turing-
complete. This may seem like a disadvantage, but it actually makes your
code much cleaner if you keep the business logic out of the templates
and allow them to concentrate on presentation. In the MVC model
templates are the View, meaning they should be presenting data- and
object structures built by the Model and the Controller.
Ben
------------------------------
Date: Tue, 22 Oct 2013 14:56:40 -0500
From: John Bokma <john@castleamber.com>
Subject: Re: Replacement for CGI.pm
Message-Id: <87eh7dnkp3.fsf@castleamber.com>
Rainer Weikusat <rweikusat@mobileactivedefense.com> writes:
> I'd like to second that, at least to a degree: Especially when building
> user interfaces, the abstraction, conditional execution and repetition
> facilities of a 'real' programming language enable working with form
> elements at a much higher level than HTML or 'some templating languages
> based on html'[*] usually do. Eg, this is a (partial) real-world example
> of code creating a form:
>
> sub form()
> {
> return ($cgi->start_form(-action => 'vmecs-create.cgi'),
>
> $cgi->table(7, #{ border => 1 },
> $cgi->t_r(menu('company')),
>
> $cgi->empty_line(),
>
> two_params(['name', 20, MAX_DNS_LABEL],
> ['dns_domain', 40, MAX_DNS_NAME]),
With TT you can make a macro to do this. That's what I've been doing the
past years; I have several macros that make building forms very easy,
Conditional execution and repetition are all easy to do with
Template::Toolkit.
--
John Bokma j3b
Blog: http://johnbokma.com/ Perl Consultancy: http://castleamber.com/
Perl for books: http://johnbokma.com/perl/help-in-exchange-for-books.html
------------------------------
Date: Tue, 22 Oct 2013 22:01:48 -0700
From: Xho Jingleheimerschmidt <xhoster@gmail.com>
Subject: Re: Replacement for CGI.pm
Message-Id: <l47l8j$h67$1@dont-email.me>
On 10/22/13 06:51, Bernie Cosell wrote:
> CGI.pm is very old and I gather that its use is deprecated.
I don't think I'd be keen to use any module that was not old enough and
widely used enough to accumulate a few neurotic haters.
> Is there a
> better/newer package for handling the CGI interface between Perl and the
> web server? We use it both ways: to parse the incoming variables [and
> cookies] and to generate the outgoing HTML. Our needs are pretty simple:
> just those two functions. It seems to work, and we really haven't had any
> trouble, but see more and more reports that one should *never* use
> CGI.pm... And so : if not, what to use instead? THANKS!!
I have no plans to stop using CGI, because my needs on that front are
also very simple and it mostly serves them well. And it is pure perl,
so if worst comes to worst you can run your own copy of it until support
for Perl 5 completely goes away.
On the other hand if I were learning from scratch, I might pick
something different to learn. The problem is there are so many flavors
of the day, how would you pick the one for it to be?
Xho
------------------------------
Date: Wed, 23 Oct 2013 14:08:06 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Replacement for CGI.pm
Message-Id: <87r4bc879l.fsf@sable.mobileactivedefense.com>
Ben Morrow <ben@morrow.me.uk> writes:
> Quoth Rainer Weikusat <rweikusat@mobileactivedefense.com>:
>> Joachim Pense <snob@pense-mainz.eu> writes:
>> >
>> > I feel that writing HTML using CGI.pm with its factoring possibilities
>> > is far more elegant than using templates; I use it even for static web
>> > pages. The goal is never use any of < and > when writing HTML.
>>
>> I'd like to second that, at least to a degree: Especially when building
>> user interfaces, the abstraction, conditional execution and repetition
>> facilities of a 'real' programming language enable working with form
>> elements at a much higher level than HTML or 'some templating languages
>> based on html'[*] usually do.
>
> TT2 allows all those things, with the advantage of not being Turing-
> complete. This may seem like a disadvantage, but it actually makes your
> code much cleaner if you keep the business logic out of the templates
> and allow them to concentrate on presentation.
It actually makes my code much cleaner when I can use a more powerful
programming language to build domain-specific abstractions for output
generation instead of being restricted to the 'generic, interpolated tag
soup' model, IOW, HTML-generation is a complex task in its own right and
using some kind of 'Logo for HTML-Editor-Jet-Pilots' instead just
restricts the options available to me for doing that. There's an "It
could be done, hence, it will be done" assumption in your statement
which is really a non-sequitur: Options don't chose themselves (I'm also
firmly convinced that the idea to stop people from making bad choices by
preventing them from making any choices is very misguided: If someone
thinks $opinion is really the Right Thing To Do[tm], the sensible
approach is to try to educate others to help them see the error in their
ways, not to force them to pay as little lip service to the superior
approach as they're capable of getting away with grudgingly).
There was no general 'program logic' not related to output generation in
the code snipped I posted. The code which is supposed to process the
inputs gathered from the form in order to effect something is
different but since the whole is just 723 lines of text, splitting the
logically separate parts into different files didn't seem necessary to
me.
> In the MVC model templates are the View, meaning they should be
> presenting data- and object structures built by the Model and the
> Controller.
'The Model and the Controller' sounds very much like 'The Beauty and the
Beast' (or maybe 'the young, female intern and the hideous accountant'
:->) to me ...
------------------------------
Date: Wed, 23 Oct 2013 22:57:11 +0300
From: George Mpouras <gravitalsun@hotmail.foo>
Subject: Re: Replacement for CGI.pm
Message-Id: <l499n3$1g55$1@news.ntua.gr>
Στις 22/10/2013 16:51, ο/η Bernie Cosell έγραψε:
> CGI.pm is very old and I gather that its use is deprecated. Is there a
> better/newer package for handling the CGI interface between Perl and the
> web server? We use it both ways: to parse the incoming variables [and
> cookies] and to generate the outgoing HTML. Our needs are pretty simple:
> just those two functions. It seems to work, and we really haven't had any
> trouble, but see more and more reports that one should *never* use
> CGI.pm... And so : if not, what to use instead? THANKS!!
>
> /Bernie\
>
Maybe for you if you think so.
I can do everything with CGI, faster that you can do with these fancy
modules.
------------------------------
Date: Wed, 23 Oct 2013 23:17:40 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Replacement for CGI.pm
Message-Id: <4hulja-s042.ln1@anubis.morrow.me.uk>
Quoth Rainer Weikusat <rweikusat@mobileactivedefense.com>:
> Ben Morrow <ben@morrow.me.uk> writes:
> >
> > TT2 allows all those things, with the advantage of not being Turing-
> > complete. This may seem like a disadvantage, but it actually makes your
> > code much cleaner if you keep the business logic out of the templates
> > and allow them to concentrate on presentation.
>
> It actually makes my code much cleaner when I can use a more powerful
> programming language to build domain-specific abstractions for output
> generation instead of being restricted to the 'generic, interpolated tag
> soup' model, IOW, HTML-generation is a complex task in its own right
I have to disagree there. It really isn't that complicated to generate
the HTML once you've got as far as a data structure suitable for
display, and the sort of abstraction which is helpful is better provided
by a slightly-souped-up macro language than by a full programming
language. If we were talking about generating something XML-based (or
some other more-structured format) I might say that something along the
lines of XSLT, that treats the document as a structure rather than raw
text, might be useful, but HTML basically is just tag soup so that sort
of thing doesn't really help.
> and
> using some kind of 'Logo for HTML-Editor-Jet-Pilots' instead just
> restricts the options available to me for doing that. There's an "It
> could be done, hence, it will be done" assumption in your statement
> which is really a non-sequitur: Options don't chose themselves (I'm also
> firmly convinced that the idea to stop people from making bad choices by
> preventing them from making any choices is very misguided: If someone
> thinks $opinion is really the Right Thing To Do[tm], the sensible
> approach is to try to educate others to help them see the error in their
> ways, not to force them to pay as little lip service to the superior
> approach as they're capable of getting away with grudgingly).
As usual, you are accusing me of trying to restrict others' choices,
when in fact I am simply explaining the reasons for my own. I wish you
would stop doing this: it's extremely tiresome. (I don't even
necessarily think in this case that others need to see the error of
their ways: if you like writing HTML in Perl that's just fine. I don't
think it helps.)
> There was no general 'program logic' not related to output generation in
> the code snipped I posted.
I didn't say there was. There was also very little that wouldn't have
been rather clearer written in real HTML, with a couple of macros where
there was actually some abstraction.
Ben
------------------------------
Date: Tue, 22 Oct 2013 13:27:39 -0700
From: Cal Dershowitz <cal@example.invalid>
Subject: Re: using File::Spec to figure out that Path::Class is really what I want
Message-Id: <k-qdnaVWDeMpQvvPnZ2dnUVZ_r-dnZ2d@supernews.com>
On 10/17/2013 03:03 AM, Ben Morrow wrote:
>
> Quoth Cal Dershowitz <Cal@example.invalid>:
>>
> [stat and chmod]
>>
>> Ok, thanks Ben. This is output on a windows 8 laptop:
>
> Note that Unix permissions don't apply on Windows. Perl pretends that
> stat and chmod work as they do on Unix, but the Windows permissions
> system is really quite different.
Roger that, and how.... I'm able to development on windows along these
lines now and achieved what the nominal goal was: mechanizing the
creation and upload of an html page such that it could be done remotely.
Using this linux machine as a server, I used a Putty terminal to make
this, which fits specification:
http://merrillpjensen.com/pages/PathClass1.html
>
>> while ($_ = $rd4->next) {
>> next unless -d $_;
>> say "dir is $_";
>> my $st = $_->stat();
>> my $mode = $st->mode();
>> say "mode is $mode";
>> my $uid = $st->uid();
>> say "uid is $uid";
>> }
>>
>> Q1) Does either of the calls I made to File::stat methods say anything
>> relevant to the permissions of the directories?
>
> Yes, the ->mode member of the stat structure contains the permissions
> bits. See perldoc -f stat for an example of using the S_ function from
> Fcntl to decode it. I don't know what the uid member contains under
> Windows, but I suspect it's useless.
We have to discuss what MS is up to, if we want to talk about perl
portability issues, and they have a differing paradigm, which is simply
different than unix's. I now find the files that created that page are
locked as I look at them as the user in whose space they created. Since
I've reached my goal for the perl part of it, I think I'm gonna take up
the shell issues elsewhere.
>
>> Q2) Path::Class has its own mechanism for while'ing over a directory
>> which seems to work. Why does this not?
>>
>> my $srd4 = $rd4->stringify;
>> my @files = <$srd4*>;
>
> Probably because $srd4 does not end with a slash. I told you before: you
> should construct a file path with a filename of "*", and then pass that
> to glob. With Path::Class this would be
>
> my @files = glob $rd4->file("*");
>
> Ben
>
Thx, Ben, that now makes sense to me. I re-wrote most of this in terms
of references and successfully dereferenced when necessary. I chopped
it up into subs that I stuffed into a module. fog1 will be the last
stable version of it.
#!/usr/bin/perl -w
use strict;
use 5.010;
use lib "template_stuff";
use fog1 qw(get_ftp_object get_content get_html_filename
create_html_file write_header write_footer);
use Cwd;
use File::Basename;
use Net::FTP;
use Path::Class;
use File::Slurp;
my $ts = "template_stuff";
my $images = "images";
my $captions = "captions";
my $current = cwd;
# directory list: @a.
my $rd2 = dir($current);
my @a = $rd2->dir_list();
my $srd2 = $rd2->stringify;
say "a is @a";
say "-------------";
my $title = $rd2->basename;
print "title is $title";
# page params
my %vars = (
title => $title,
headline => "File manipulation with Path::Class",
place => 'Oakland',
css_file => "${title}1.css",
header => file($ts,"hc_input2.txt"),
footer => file($ts,"footer_center.txt"),
css_local => file($ts,"rad1.css"),
body => file($ts,"rebus1.tmpl"),
);
#main control
my $rvars = \%vars;
my $rftp = get_ftp_object();
my $html_file = get_html_filename($rftp);
my $fh = create_html_file ($html_file);
my $remote_dir = $html_file;
$remote_dir =~ s/\.html$//;
say "remote_dir is $remote_dir";
# create header
my $rhdr = write_header($rvars);
print $$rhdr;
print $fh $$rhdr;
my $specifier = read_file( $vars{"body"} ) ;
print "specifier is $specifier\n";
# print content to file
my $refc = get_content($ts);
say "----------";
my %content = %$refc;
foreach my $key (sort keys %content) {
printf $fh $specifier,$remote_dir,$key,$content{$key};
}
my $rftr = write_footer($rvars);
print $fh $$rftr;
close $fh;
#load html file to server
$rftp->cwd("/pages") or warn "cwd failed $!\n";
$rftp->put($html_file) or die "put failed $!\n";
#load css file to server
$rftp->cwd("/css") or warn "cwd failed $@\n";
my $path3 = file(@a, $vars{"css_local"});
print "path3 is $path3\n";
my $remote_css = $vars{"css_file"};
print "remote file is $remote_css\n";
$rftp->put("$path3", $remote_css) or warn "put failed $@\n";
# load images
#create remote directory in images
$rftp->binary or die "$!\n";
$rftp->cwd("/images") or warn "cwd failed $!\n";
$rftp->mkdir($remote_dir) or warn "cwd failed $!\n";
$rftp->cwd($remote_dir)
or die "Cannot change working directory ", $rftp->message;
for my $key (keys %{$refc}) {
print "$key => ${$refc}{$key}\n";
my $a = file(@a,$ts,$images,$key);
my $sa = $a->stringify;
say "a is $a";
my $b = file($key);
my $sb = $b->stringify;
say "b is $b";
$rftp->put($sa, $sb) or warn "put failed $@\n";
}
$rftp->ls;
$rftp->quit();
print "new file is \n";
print "$html_file\n";
--
Cal
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 4062
***************************************
