[28866] in Perl-Users-Digest
Perl-Users Digest, Issue: 110 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Feb 9 22:36:15 2007
Date: Fri, 9 Feb 2007 19:35:36 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Fri, 9 Feb 2007 Volume: 11 Number: 110
Today's topics:
More Multiple Classes per File (was Pretty Format...) <please@nospam.net>
Re: More Multiple Classes per File (was Pretty Format.. <bik.mido@tiscalinet.it>
Re: More Multiple Classes per File (was Pretty Format.. anno4000@radom.zrz.tu-berlin.de
Re: More Multiple Classes per File <spamtrap@dot-app.org>
Re: More Multiple Classes per File <uri@stemsystems.com>
Re: More Multiple Classes per File <bik.mido@tiscalinet.it>
Multiple CGI forms on one page <keflavich@gmail.com>
Re: Multiple CGI forms on one page <spamtrap@dot-app.org>
Re: Multiple CGI forms on one page <greg.ferguson@icrossing.com>
Re: Multiple CGI forms on one page <bik.mido@tiscalinet.it>
Re: Multiple CGI forms on one page <keflavich@gmail.com>
Re: Multiple CGI forms on one page <spamtrap@dot-app.org>
Re: Multiple CGI forms on one page <keflavich@gmail.com>
Re: Multiple CGI forms on one page xhoster@gmail.com
Re: Multiple CGI forms on one page <spamtrap@dot-app.org>
Re: Multiple CGI forms on one page <bik.mido@tiscalinet.it>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Wed, 07 Feb 2007 15:07:33 -0800
From: Xiong Changnian <please@nospam.net>
Subject: More Multiple Classes per File (was Pretty Format...)
Message-Id: <please-1EE0A8.15073307022007@free.teranews.com>
In article <52u355F1qbe5qU1@mid.dfncis.de>,
anno4000@radom.zrz.tu-berlin.de wrote:
> Put a bare block around each class definition, so you isolate lexicals
> and can re-use variable names.
Ah, that's the kind of sweetener that I really appreciate. I avoid
globals like the plague but the block makes the whole multiple-class
approach more palatable. Thank you.
In article <x7d54l7jhe.fsf@mail.sysarch.com>,
Uri Guttman <uri@stemsystems.com> wrote:
you need to understand how these names and calls relate to each
> other and not guess and thrash about.
Well, guessing and thrashing is preferred approach for some but I agree
with you that it's good to know what's *really* happening. I will go
over your explanation several times and construct a number of dummy
setups to exercise the limits of these paradigms.
I think key to all of this is that packages that contain subs intended
to be called as functions need to handled a bit differently from
packages that implement classes, whose subs are methods. When I go in, I
go in with both feet, so my current solution is pure OO. I will be
exporting no symbols with EXPORTER.
In article <x7hctx7ksy.fsf@mail.sysarch.com>,
Uri Guttman <uri@stemsystems.com> wrote:
> you used a for loop with the implied use of $_ as the loop variable. it
> is better to use a named lexical variable...
Well, I won't argue the point. But for now, I'm learning, and it's
better for me to exercise these default variables heavily, so I can
comprehend code that uses them implicitly. Okay?
> you don't have to tell us your background regarding declarations. most
> of the regulars here know multiple langs and know all about this area.
Better than I, no doubt. That was a "where I'm coming from" snippet.
Maybe it says something about "where I'm going" -- maybe not. Sorry if
you found it digressive. Let's just say I've turned my back firmly on
toggling in commands via front-panel switches. I'm going for maximum
abstraction and extensibility.
They say a caller should not know anything about what's inside an
object; I'm going one better and trying to write methods that don't
assume much about the innards, either. The rubber has to meet the road
sometime, of course.
> it is BAD coding to use symrefs if there is a better
> way to do it. that is why use strict disallows them.
I couldn't agree more. I don't know how to reject this approach more
explicitly. I did it, I'm glad I did it, I'm glad it worked. I came here
to figure out a better way to do it and, with your help, I did. Thank
you.
Xiong
--
Xiong Changnian
xiong102ATxuefangDOTcom
--
Posted via a free Usenet account from http://www.teranews.com
------------------------------
Date: Thu, 08 Feb 2007 17:31:07 +0100
From: Michele Dondi <bik.mido@tiscalinet.it>
Subject: Re: More Multiple Classes per File (was Pretty Format...)
Message-Id: <lrjms29u3t2enpr5itc1t71fuqaki9nud3@4ax.com>
On Wed, 07 Feb 2007 15:07:33 -0800, Xiong Changnian
<please@nospam.net> wrote:
>packages that implement classes, whose subs are methods. When I go in, I
>go in with both feet, so my current solution is pure OO. I will be
>exporting no symbols with EXPORTER.
Well, the two approaches are not mutually exclusive in the strictest
sense. Mixing them would just be plain unusual. There may well be some
OO module also exporting some symbol, but none that springs to mind
now. Indeed one must have a very good reason to do so!
>> you used a for loop with the implied use of $_ as the loop variable. it
>> is better to use a named lexical variable...
>
>Well, I won't argue the point. But for now, I'm learning, and it's
>better for me to exercise these default variables heavily, so I can
>comprehend code that uses them implicitly. Okay?
Don't do it *heavily*. Do it *as appropriate*. Of course, what is
appropriate is in the eye of the beholder - see Uri's comment itself,
from which I beg to differ, BTW.
Michele
--
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
.'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,
------------------------------
Date: 8 Feb 2007 17:03:29 GMT
From: anno4000@radom.zrz.tu-berlin.de
Subject: Re: More Multiple Classes per File (was Pretty Format...)
Message-Id: <5313f1F1qk7duU1@mid.dfncis.de>
Michele Dondi <bik.mido@tiscalinet.it> wrote in comp.lang.perl.misc:
> On Wed, 07 Feb 2007 15:07:33 -0800, Xiong Changnian
> <please@nospam.net> wrote:
>
> >packages that implement classes, whose subs are methods. When I go in, I
> >go in with both feet, so my current solution is pure OO. I will be
> >exporting no symbols with EXPORTER.
>
> Well, the two approaches are not mutually exclusive in the strictest
> sense. Mixing them would just be plain unusual. There may well be some
> OO module also exporting some symbol, but none that springs to mind
> now. Indeed one must have a very good reason to do so!
There are examples.
It can make a lot of sense to export a constructor (->new, or a somewhat
curried version thereof) under the class name itself:
package MyClass;
our @EXPORT_OK = __PACKAGE__;
sub new {
my $class = shift;
# ....
}
sub MyClass { __PACKAGE__->new( @_) }
This is briefly discussed in perltooc (look for "export"), where
an example in _The Perl Cookbook_ is mentioned.
Anno
------------------------------
Date: Thu, 08 Feb 2007 16:33:02 -0500
From: Sherm Pendley <spamtrap@dot-app.org>
Subject: Re: More Multiple Classes per File
Message-Id: <m2odo4gws1.fsf@local.wv-www.com>
Michele Dondi <bik.mido@tiscalinet.it> writes:
> On Wed, 07 Feb 2007 15:07:33 -0800, Xiong Changnian
> <please@nospam.net> wrote:
>
>>packages that implement classes, whose subs are methods. When I go in, I
>>go in with both feet, so my current solution is pure OO. I will be
>>exporting no symbols with EXPORTER.
>
> Well, the two approaches are not mutually exclusive in the strictest
> sense. Mixing them would just be plain unusual. There may well be some
> OO module also exporting some symbol, but none that springs to mind
> now. Indeed one must have a very good reason to do so!
CGI.pm can export non-OO functions, but doesn't by default. Data::Dumper
supports a dual interface as well.
Granted, they're the exceptions, not the rule - it *is* unusual to offer
both interfaces. It's nice for your users though, if there are a lot of
them and no clear consensus as to which style they prefer.
sherm--
--
Web Hosting by West Virginians, for West Virginians: http://wv-www.net
Cocoa programming in Perl: http://camelbones.sourceforge.net
------------------------------
Date: Thu, 08 Feb 2007 23:30:19 -0500
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: More Multiple Classes per File
Message-Id: <x7bqk42bs4.fsf@mail.sysarch.com>
>>>>> "SP" == Sherm Pendley <spamtrap@dot-app.org> writes:
SP> Michele Dondi <bik.mido@tiscalinet.it> writes:
>> On Wed, 07 Feb 2007 15:07:33 -0800, Xiong Changnian
>> <please@nospam.net> wrote:
>>
>>> packages that implement classes, whose subs are methods. When I go in, I
>>> go in with both feet, so my current solution is pure OO. I will be
>>> exporting no symbols with EXPORTER.
>>
>> Well, the two approaches are not mutually exclusive in the strictest
>> sense. Mixing them would just be plain unusual. There may well be some
>> OO module also exporting some symbol, but none that springs to mind
>> now. Indeed one must have a very good reason to do so!
SP> CGI.pm can export non-OO functions, but doesn't by default. Data::Dumper
SP> supports a dual interface as well.
SP> Granted, they're the exceptions, not the rule - it *is* unusual to offer
SP> both interfaces. It's nice for your users though, if there are a lot of
SP> them and no clear consensus as to which style they prefer.
i had once planned a module called something like Class::Procedural. it
would be used by OO modules to offer an optional procedural
interface. the exported subs would all work on the default object and be
wrappers on the object methods. but someone i know showed me his module
(gotta find him on irc to get the name) which has this feature (among
others) already in it. anyhow it is an interesting concept since many
times when you use OO modules there is only one of the objects in use
at a time so a procedural interface would work and keep things slightly
cleaner (all those redundant $obj-> are gone).
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
------------------------------
Date: Fri, 09 Feb 2007 13:37:05 +0100
From: Michele Dondi <bik.mido@tiscalinet.it>
Subject: Re: More Multiple Classes per File
Message-Id: <2lqos29j022oed03d6lev77v158tjp8283@4ax.com>
On Thu, 08 Feb 2007 16:33:02 -0500, Sherm Pendley
<spamtrap@dot-app.org> wrote:
>> Well, the two approaches are not mutually exclusive in the strictest
>> sense. Mixing them would just be plain unusual. There may well be some
>> OO module also exporting some symbol, but none that springs to mind
>> now. Indeed one must have a very good reason to do so!
>
>CGI.pm can export non-OO functions, but doesn't by default. Data::Dumper
>supports a dual interface as well.
Oh, yes, CGI.pm... actually I knew that. However I was thinking more
of what Anno suggested in terms of exporting a constructor, or however
functions supposed to operate on objects.
Michele
--
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
.'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,
------------------------------
Date: 8 Feb 2007 13:24:00 -0800
From: "Keflavich" <keflavich@gmail.com>
Subject: Multiple CGI forms on one page
Message-Id: <1170969840.354250.258000@q2g2000cwa.googlegroups.com>
I'm trying to make a page that effectively has a menu to choose two
options. The first, it uploads a file, reads it, compares it to
another file on the host computer. The second, it opens up a new form
on the same page to input data and compare to the same file on the
host computer.
Currently, the first option works great. The second option does
create the additional form, but when I submit the second form the page
clears back to its original state. Of course, this makes some sense
to me, seeing as I'm posting only the contents of the second form, but
I hoped there was a way around it.
I'm also trying to dynamically create portions of the page - i.e., one
button outputs some data that includes other buttons, which, when
clicked, would "expand" and show more data.
My description above is pretty vague, so I'm sure I'll need to clarify
some; I don't think I have a great grasp of the terminology. But I
think a simple question to answer would be, "How do you have a second
form submit (POST) all parameters from previous forms when it must be
a separate form?"
I tried searching the forums and google for some answer, but I have no
idea what exactly I'm searching for. I'd be happy with some good
links describing how to do this. BTW, I'm using CGI.pm.
Thanks,
Adam
------------------------------
Date: Thu, 08 Feb 2007 17:03:06 -0500
From: Sherm Pendley <spamtrap@dot-app.org>
Subject: Re: Multiple CGI forms on one page
Message-Id: <m2fy9ggvdx.fsf@local.wv-www.com>
"Keflavich" <keflavich@gmail.com> writes:
> think a simple question to answer would be, "How do you have a second
> form submit (POST) all parameters from previous forms when it must be
> a separate form?"
>
> I tried searching the forums and google for some answer, but I have no
> idea what exactly I'm searching for. I'd be happy with some good
> links describing how to do this. BTW, I'm using CGI.pm.
If you use CGI.pm's built-in methods to create the form elements, then
they're "sticky" by default. That is, the value element or contents of
the created form element will be that of the incoming parameter of the
same name.
The very first example at the top of "perldoc CGI" shows this behavior.
It creates a form that submits back to the same script that created it.
The first time, there's no incoming params, so the form inputs are empty;
after that, they repeat the submitted value.
sherm--
--
Web Hosting by West Virginians, for West Virginians: http://wv-www.net
Cocoa programming in Perl: http://camelbones.sourceforge.net
------------------------------
Date: 8 Feb 2007 14:40:28 -0800
From: "gf" <greg.ferguson@icrossing.com>
Subject: Re: Multiple CGI forms on one page
Message-Id: <1170974428.801324.36380@v33g2000cwv.googlegroups.com>
On Feb 8, 2:24 pm, "Keflavich" <keflav...@gmail.com> wrote:
> I'm trying to make a page that effectively has a menu to choose two
> options. The first, it uploads a file, reads it, compares it to
> another file on the host computer. The second, it opens up a new form
> on the same page to input data and compare to the same file on the
> host computer.
>
> Currently, the first option works great. The second option does
> create the additional form, but when I submit the second form the page
> clears back to its original state. Of course, this makes some sense
> to me, seeing as I'm posting only the contents of the second form, but
> I hoped there was a way around it.
>
> I'm also trying to dynamically create portions of the page - i.e., one
> button outputs some data that includes other buttons, which, when
> clicked, would "expand" and show more data.
>
> My description above is pretty vague, so I'm sure I'll need to clarify
> some; I don't think I have a great grasp of the terminology. But I
> think a simple question to answer would be, "How do you have a second
> form submit (POST) all parameters from previous forms when it must be
> a separate form?"
It sounds like you'll need to look into the CSS "display" attributes,
or the Javascript equivalents that toggle those settings in the page's
DOM.
The "Dynamic HTML" book covers all that. Or, you can wander over to
the comp.lang.javascript or comp.infosystems.www.authoring.stylesheets
newsgroups and ask there. Or, use "the google" or wikipedia to search
for more info. It's a common task, but has lots of little gotchas
depending on your page design, so you'll do better going to those
experts as this isn't really a Perl or CGI.pm issue.
------------------------------
Date: Thu, 08 Feb 2007 23:43:18 +0100
From: Michele Dondi <bik.mido@tiscalinet.it>
Subject: Re: Multiple CGI forms on one page
Message-Id: <dr9ns2pke9frh221e99lfs5ahrrnb3reer@4ax.com>
On 8 Feb 2007 13:24:00 -0800, "Keflavich" <keflavich@gmail.com> wrote:
>Subject: Multiple CGI forms on one page
The following PM node may be of some interest to you:
http://perlmonks.org/?node_id=597286
Michele
--
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
.'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,
------------------------------
Date: 8 Feb 2007 15:28:48 -0800
From: "Keflavich" <keflavich@gmail.com>
Subject: Re: Multiple CGI forms on one page
Message-Id: <1170977328.193789.136440@a75g2000cwd.googlegroups.com>
> The following PM node may be of some interest to you:
>
> http://perlmonks.org/?node_id=597286
Thanks Michele, I think that's what I'm looking for, especially this
reply: http://perlmonks.org/?node_id=597320. I'm not sure how I
missed perlmonks in my previous searches.
gf - I'll try using dhtml or stylesheets if this fails, but I don't
think that's the solution I'm looking for. Besides, I haven't used
stylesheets for over a year and I don't want to relearn them right
now.
Sherm - the simple example definitely isn't want I'm looking for; my
output page includes a new form that disappears when I submit it. I
also don't understand the statement, "That is, the value element or
contents of the created form element will be that of the incoming
parameter of the same name," at least not in context. Certainly, the
values in any form I submit will be readable with
param('parameter_name'), but what about the forms I submitted the
first time?
Thanks for the help,
Adam
------------------------------
Date: Thu, 08 Feb 2007 18:48:50 -0500
From: Sherm Pendley <spamtrap@dot-app.org>
Subject: Re: Multiple CGI forms on one page
Message-Id: <m2tzxwfbx9.fsf@local.wv-www.com>
"Keflavich" <keflavich@gmail.com> writes:
> Sherm - the simple example definitely isn't want I'm looking for; my
> output page includes a new form that disappears when I submit it. I
> also don't understand the statement, "That is, the value element or
> contents of the created form element will be that of the incoming
> parameter of the same name," at least not in context. Certainly, the
> values in any form I submit will be readable with
> param('parameter_name'), but what about the forms I submitted the
> first time?
CGI.pm does two things - it parses incoming input, *and* it can create
form elements to include in its output.
If you have (for example) an text field named "foo", and someone fills
it in with "bar", then you can do this:
my $foo_field = $req->textfield('foo');
You didn't have to specify the value - CGI.pm will pick it up from the input
parameter of the same name. This is a great feature when you need to, for
example, return a form with everything the user entered intact, but a couple
of input fields flagged with error messages.
But, self-referential forms w/error checking aren't the only thing CGI.pm's
"sticky" feature is useful for. You can also use it for "multi-page" forms,
passing along the value of 'foo' along to the next form in the series as a
hidden input element:
my $hidden_foo = $req->input(-type=>'hidden', -name=>'foo');
If I follow what you're asking for, then what you're doing is going through
a series of forms. You want each form's params to carry over to the next, so
that you can use them all when the last form is submitted.
No offense meant, but if you think the first example in the CGI.pm doc isn't
relevant to what you're asking for, then you didn't understand the example.
Either that, or I've misunderstood what you're asking for. :-)
sherm--
--
Web Hosting by West Virginians, for West Virginians: http://wv-www.net
Cocoa programming in Perl: http://camelbones.sourceforge.net
------------------------------
Date: 8 Feb 2007 16:35:35 -0800
From: "Keflavich" <keflavich@gmail.com>
Subject: Re: Multiple CGI forms on one page
Message-Id: <1170981335.463070.180810@j27g2000cwj.googlegroups.com>
> If you have (for example) an text field named "foo", and someone fills
> it in with "bar", then you can do this:
>
> my $foo_field = $req->textfield('foo');
>
> You didn't have to specify the value - CGI.pm will pick it up from the input
> parameter of the same name. This is a great feature when you need to, for
> example, return a form with everything the user entered intact, but a couple
> of input fields flagged with error messages.
So $req is the name of the form I should already have printed? e.g.
print $req=start_form,textfield(),end_form; ?
> But, self-referential forms w/error checking aren't the only thing CGI.pm's
> "sticky" feature is useful for. You can also use it for "multi-page" forms,
> passing along the value of 'foo' along to the next form in the series as a
> hidden input element:
>
> my $hidden_foo = $req->input(-type=>'hidden', -name=>'foo');
Ermm... what does input do? Or are you just using that as a generic
term for any cgi input, say hidden() or textfield()? perldoc CGI |
grep input gives me no commands of that sort. I tried it out and got
a text input form, but none of the input parameters worked - they
showed up as text. My guess is that's deprecated syntax at best.
> If I follow what you're asking for, then what you're doing is going through
> a series of forms. You want each form's params to carry over to the next, so
> that you can use them all when the last form is submitted.
>
> No offense meant, but if you think the first example in the CGI.pm doc isn't
> relevant to what you're asking for, then you didn't understand the example.
> Either that, or I've misunderstood what you're asking for. :-)
None taken, but I'm still not sure I understand how that example
pertains to what I'm doing. I'm not echoing back the input values,
I'm echoing back a new form, and which new form is echoed depends on
the user input. I do think you're right in that it should work out
correctly if I just keep passing on the input stuff (i.e. either print
or somehow output hidden(-name=>'mode',-value=>"input stuff) ), but
it's not working out.
So let me try to rephrase what I'm doing, and show the problems I'm
having (I'm trying now to follow the method in the above link, which
I guess is a generalization of the CGI.pm synopsis example) [very
simplified/incomplete version of my code]:
my %modes = (
web_interactive => \&single_source_web,
upload_file => \&multisource,
default => \&default_menu,
);
sub default_menu {
print start_multipart_form, filefield(-name=>'infile',-
default=>'test_measurements.dat',-size=>80,-maxlength=>80),
submit(-name=>'submit_file',-value=>'Upload File'),
submit(-name=>'single-source',-value=>'Single-source (no upload)'),
end_form,hr;
if (param('single-source')) {
print hidden(-name=>'mode',-default=>'web_interactive');
}
elsif (param('submit_file')) {
$user_file=upload('infile');
print hidden(-name=>'mode',-default=>'upload_file');
}
}
sub single_source_web {
}
sub multisource {
}
So, current problem with this code: the subroutines are not called.
If I call them directly in the above if statements, they work, but...
I take it back, they work. I think my problem is solved; the
important thing is for the if statement to include both the hidden
parameter and the function call.
if (param('single-source')) {
print hidden(-name=>'mode',-default=>'web_interactive');
single_source_web();
}
but I still maintain the first example wasn't enough.
Thanks for your help,
Adam
------------------------------
Date: 09 Feb 2007 01:00:20 GMT
From: xhoster@gmail.com
Subject: Re: Multiple CGI forms on one page
Message-Id: <20070208200052.489$7p@newsreader.com>
"Keflavich" <keflavich@gmail.com> wrote:
> I'm trying to make a page that effectively has a menu to choose two
> options. The first, it uploads a file, reads it, compares it to
> another file on the host computer. The second, it opens up a new form
> on the same page to input data and compare to the same file on the
> host computer.
>
> Currently, the first option works great. The second option does
> create the additional form, but when I submit the second form the page
> clears back to its original state. Of course, this makes some sense
> to me, seeing as I'm posting only the contents of the second form, but
> I hoped there was a way around it.
I have a lot of programs that look something like this
(in highly compacted and simplified form):
unless ($q->param('step_1')) { # haven't done step 1 yet
print whatever_form__for_step1();
exit;
};
print $q->hidden('step_1'); # save step 1
unless ($q->param('step_2') { # haven done step 2 yet
print whatever_form_for_step2($q->param('step_1'));
exit;
};
print $q->hidden('step_2') {
## etc.
Of course, if the form for step_2 doesn't change depending on the input
provided in step_1, then there is no reason for them to be separate steps.
Xho
--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB
------------------------------
Date: Thu, 08 Feb 2007 22:15:10 -0500
From: Sherm Pendley <spamtrap@dot-app.org>
Subject: Re: Multiple CGI forms on one page
Message-Id: <m2ps8kf2dd.fsf@local.wv-www.com>
"Keflavich" <keflavich@gmail.com> writes:
>> If you have (for example) an text field named "foo", and someone fills
>> it in with "bar", then you can do this:
>>
>> my $foo_field = $req->textfield('foo');
>>
>> You didn't have to specify the value - CGI.pm will pick it up from the input
>> parameter of the same name. This is a great feature when you need to, for
>> example, return a form with everything the user entered intact, but a couple
>> of input fields flagged with error messages.
>
> So $req is the name of the form I should already have printed? e.g.
> print $req=start_form,textfield(),end_form; ?
Sorry - I'm used to using the OOP interface to CGI.pm. No, $req is just the
CGI request object:
my $req = CGI->new();
print $req->header,
$req->start_html,
$req->start_form,
$req->textfield(-name => 'foo'),
$req->end_form;
>> But, self-referential forms w/error checking aren't the only thing CGI.pm's
>> "sticky" feature is useful for. You can also use it for "multi-page" forms,
>> passing along the value of 'foo' along to the next form in the series as a
>> hidden input element:
>>
>> my $hidden_foo = $req->input(-type=>'hidden', -name=>'foo');
>
> Ermm... what does input do?
The above creates an <input type="hidden" name="foo"> element. If there is
an incoming param('foo'), its value will be passed along as well - in this
case in the value attribute. Other types of form elements, like checkboxes,
select lists, or text areas, have their values supplied in other ways, but
the principle is the same; the value that's used to generate the HTML is
taken from the param() input of the same name.
You could do the same thing manually of course, with:
my $hidden_foo = '<input type="hidden" name="foo" value="' .
param('foo') ? param('foo') : 'default' . '">'
And that's actually not too hard for something simple like a hidden field,
but for more complex input like a multiple-choice select list, it can get
to be a pain. To avoid that pain, CGI.pm was written to automatically take
incoming param()s and use them to "fill out" outgoing HTML elements.
> Or are you just using that as a generic
> term for any cgi input, say hidden() or textfield()?
It wasn't generic, no - <input ...> is a real HTML element. But the same
technique works just as well with other elements. The hidden() method is
just a shortcut way of calling input(-type=>'hidden').
> grep input gives me no commands of that sort.
That's because a list of all those methods (not commands) would be a list
of all possible HTML elements. In general, if you want to produce an HTML
element such as <foo>, you can do so by calling the CGI method $req->foo().
And yes, that *was* a generic example. :-)
> None taken, but I'm still not sure I understand how that example
> pertains to what I'm doing. I'm not echoing back the input values,
> I'm echoing back a new form, and which new form is echoed depends on
> the user input. I do think you're right in that it should work out
> correctly if I just keep passing on the input stuff (i.e. either print
> or somehow output hidden(-name=>'mode',-value=>"input stuff) )
Yeah, sorry - I missed the second part of your question. I think you're
talking about an "expanding" form. The user fills out the top part, submits
it, and gets a longer form back; the top part of the second form is the
same as the first form, with more added below that that depends on how the
first form was filled out.
What I'm talking about will help you pass along the top form elements, so
the user doesn't have to fill them out again, but it's got nothing to do
with choosing which bottom half to send. That's a separate step.
sherm--
--
Web Hosting by West Virginians, for West Virginians: http://wv-www.net
Cocoa programming in Perl: http://camelbones.sourceforge.net
------------------------------
Date: Fri, 09 Feb 2007 15:21:16 +0100
From: Michele Dondi <bik.mido@tiscalinet.it>
Subject: Re: Multiple CGI forms on one page
Message-Id: <tm0ps2tjdgo811a3aaimfijb4ccroluj6g@4ax.com>
On 8 Feb 2007 15:28:48 -0800, "Keflavich" <keflavich@gmail.com> wrote:
>> http://perlmonks.org/?node_id=597286
>
>Thanks Michele, I think that's what I'm looking for, especially this
>reply: http://perlmonks.org/?node_id=597320. I'm not sure how I
>missed perlmonks in my previous searches.
It's a good resource. Some monks are also active here and elsewhere.
OTOH web-related questions that are more HTML/JS/whatever than Perl
are better tolerated than here.
Michele
--
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
.'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,
------------------------------
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:
#The Perl-Users Digest is a retransmission of the USENET newsgroup
#comp.lang.perl.misc. For subscription or unsubscription requests, send
#the single line:
#
# subscribe perl-users
#or:
# unsubscribe perl-users
#
#to almanac@ruby.oce.orst.edu.
NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
#To request back copies (available for a week or so), send your request
#to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
#where x is the volume number and y is the issue number.
#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 110
**************************************
