three-part form submission using CGI.pm 
Author Message
 three-part form submission using CGI.pm


[re-directed from c.l.p.modules as I think it might generate some more
discussion here [yes I should have cross-posted but I didn't think of it
at the time :( ] to help me solve this]

[jeopardectomy performed]

 | Make a bunch of hidden fields for the information in the 2nd form doing
 | this.
 |
 | foreach $param (param){$hiddeninfo .= hidden($param)."\n";}
 |
 | Then on your 3rd submission you will have the same field names and
 | stuff you need.
 |
 | B. Carlson

it seems to me that if I have to do it this way, that a map would be
more efficient.

I don't quite grok the map function yet (although I can definitely feel
the need to) .. I'm going to take a whack at this right here off the
top of my head, and invite some critique from you more experienced
map-ers.

print header, start_html, start_form,
    ( map {
          hidden({-name=>$_, -Values=>unescapeHTML(param($_))})
          } (param)
     ),
    submit(), end_form, end_html;

I tried this in my code itself, and played with it a bit, and it
otherwise seems to work fine, but it introduces another problem..

I have some textarea fields that I want the users to be able to input
in paragraph format and preserve the line breaks (for which I was using
a fix_paragraphs() sub that replaces all the \n's with <br>'s instead)

However, when I view the 'intermediate preview' now, all the \n's are
HTML-escaped by CGI.pm to be &#13;&#10; pairs (and I'm not even sure
whether this is localized to being on a Mac, or if that's normal.)
which is why I added the unescapeHTML business to the map function to
see if that would take care of it (nope).

I've tried adding those to the fix_paragraphs sub in a separate regex
but it's not catching them like I thought it would. any suggestions on
this?

--
unmunge e-mail here:
#!perl -w
print map {chr(ord($_)-3)} split //, "zhepdvwhuCzhegudjrq1qhw";
# ( damn spammers. *shakes fist* take a hint. =:P )



Wed, 06 Aug 2003 01:56:40 GMT  
 three-part form submission using CGI.pm

(snipped)

Quote:
> I tried this in my code itself, and played with it a bit, and it
> otherwise seems to work fine, but it introduces another problem..
> I have some textarea fields that I want the users to be able to input
> in paragraph format and preserve the line breaks (for which I was using
> a fix_paragraphs() sub that replaces all the \n's with <br>'s instead)
> However, when I view the 'intermediate preview' now, all the \n's are
> HTML-escaped by CGI.pm to be &#13;&#10; pairs (and I'm not even sure
> whether this is localized to being on a Mac, or if that's normal.)
> which is why I added the unescapeHTML business to the map function to
> see if that would take care of it (nope).
> I've tried adding those to the fix_paragraphs sub in a separate regex
> but it's not catching them like I thought it would. any suggestions on
> this?

Yes, a suggestion. Stop using CGI.pm and write your own
custom read and parse routine. All of your problems
associated with CGI.pm will instantly vanish.

Godzilla!



Wed, 06 Aug 2003 02:08:01 GMT  
 three-part form submission using CGI.pm

Quote:

> Yes, a suggestion. Stop using CGI.pm and write your own
> custom read and parse routine. All of your problems
> associated with CGI.pm will instantly vanish.

That's the stupidest thing I've ever read. I'm going to write and
debug a replacement for a mature piece of reuseable software? There
is no rational reason for doing so (other than as a learning
experience).

Geez, I should put
  print "Content-type: text/html\n\n";
at the top of every one of my perl scripts too!

Clayton



Wed, 06 Aug 2003 03:42:10 GMT  
 three-part form submission using CGI.pm

Quote:


> > Yes, a suggestion. Stop using CGI.pm and write your own
> > custom read and parse routine. All of your problems
> > associated with CGI.pm will instantly vanish.
> That's the stupidest thing I've ever read. I'm going to write and
> debug a replacement for a mature piece of reuseable software? There
> is no rational reason for doing so (other than as a learning
> experience).
> Geez, I should put
>   print "Content-type: text/html\n\n";
> at the top of every one of my perl scripts too!

Your comments well reflect why you
suffer so many problems attempting
to write Perl programs.

Godzilla!



Wed, 06 Aug 2003 03:47:24 GMT  
 three-part form submission using CGI.pm

Quote:

> Your comments well reflect why you
> suffer so many problems attempting
> to write Perl programs.

You're entitled to believe what you want about my Perl prowess.
And here's what I believe about yours:

More of your answers and opinionated ramblings on this newsgroup
do more of a disservice to the people asking the questions than no
answer at all.

Adieu,
Clayton



Wed, 06 Aug 2003 05:09:56 GMT  
 three-part form submission using CGI.pm

Quote:


>> Yes, a suggestion. Stop using CGI.pm and write your own custom read and
>> parse routine. All of your problems associated with CGI.pm will
>> instantly vanish.

> That's the stupidest thing I've ever read. I'm going to write and  debug
> a replacement for a mature piece of reuseable software? There  is no
> rational reason for doing so (other than as a learning  experience).

Well... it may not be the stupidist thing... and there may be rational
reasons for re-inventing the wheel, or at least redefining it.

For good or bad I've not used CGI.pm for a while.  Reuseable software is
generally a good thing, but like the M$ experience you must accept the
limitations such software imposes.  When you run into something that said
reuseable software won't do easily, then it may be time to roll your
own.  Of course your reasons for doing so should be good ones. :-)

A few years ago I was trying to make CGI.pm do something specific with
file uploading (don't remember what) and after fighting it for a day or
so decided to write my own file uploading routines.

As you point out it was an excellent learning experience. :-)

BUT!

I managed to come up with code that did not require using uninitialized
values, as (at that time) CGI.pm and other upload routines  did.
It was also sensibly faster than CGI.pm.  More to the point I could
easily go in and tweak my code to do specific things that I wanted it to do
which would be 'interesting' with CGI.pm.

Note that is not a slam of Lincoln by any stretch of the imagination.
But you simply can not expect any one person (or module) to address all
possible concerns and sometimes reusable code just doesn't do exactly
what you need it to do....

my $.02

Steve



Wed, 06 Aug 2003 06:12:01 GMT  
 three-part form submission using CGI.pm

 |
 | Yes, a suggestion. Stop using CGI.pm and write your own
 | custom read and parse routine. All of your problems
 | associated with CGI.pm will instantly vanish.

if I hadn't had CGI.pm, this would have taken me MUCH longer to complete
as far as it's gotten.

this one function alone saved me gobs of time:

      import_names('UT');

there's over 30 form params. the HELL I want to grok (i.e. import into
UT:: namespace) all of them myself when I can do it with one line of
code that works that simply.

the stumbling block has more to do with my understanding of how HTML is
parsed by the subroutines than anything inherently wrong with CGI.pm.

--
unmunge e-mail here:
#!perl -w
print map {chr(ord($_)-3)} split //, "zhepdvwhuCzhegudjrq1qhw";
# ( damn spammers. *shakes fist* take a hint. =:P )



Wed, 06 Aug 2003 07:07:50 GMT  
 three-part form submission using CGI.pm

 | > Your comments well reflect why you
 | > suffer so many problems attempting
 | > to write Perl programs.
 |
 | You're entitled to believe what you want about my Perl prowess.
 | And here's what I believe about yours:
 |
 | More of your answers and opinionated ramblings on this newsgroup
 | do more of a disservice to the people asking the questions than no
 | answer at all.

so, is anyone going to actually attempt to help me with my problem or
are we all going to follow up to Godzilla instead?

let's get back on track here. :P

6 posts and not one attempt to talk to me about what ails my perl.
enough already. :j

--
unmunge e-mail here:
#!perl -w
print map {chr(ord($_)-3)} split //, "zhepdvwhuCzhegudjrq1qhw";
# ( damn spammers. *shakes fist* take a hint. =:P )



Wed, 06 Aug 2003 07:10:35 GMT  
 three-part form submission using CGI.pm

Quote:
> print header, start_html, start_form,
>     ( map {
>           hidden({-name=>$_, -Values=>unescapeHTML(param($_))})
>           } (param)
>      ),
>     submit(), end_form, end_html;

> I tried this in my code itself, and played with it a bit, and it
> otherwise seems to work fine, but it introduces another problem..

> I have some textarea fields that I want the users to be able to input
> in paragraph format and preserve the line breaks (for which I was using
> a fix_paragraphs() sub that replaces all the \n's with <br>'s instead)

> However, when I view the 'intermediate preview' now, all the \n's are
> HTML-escaped by CGI.pm to be &#13;&#10; pairs (and I'm not even sure
> whether this is localized to being on a Mac, or if that's normal.)
> which is why I added the unescapeHTML business to the map function to
> see if that would take care of it (nope).

I think that hidden() is escaping the HTML.  If so, it's arguably
a good feature designed to prevent special characters from screwing
up your form.

I'm not quite sure what you want to do, but I'd recommend either
doing a s/&#13;&#10;/<br>/ etc on the returned hidden form values (after
they'd been resubmitted), or else place the returned data within a
<pre>...</pre> block as is.

HTH
--
Joe Schaefer       Then the King smiled.  "A hard day," he'd say, "full of
                nizzardly worries.  A long day," he'd say. "Now it's time for
                                          some fun!"
                                               -- Dr. Seuss



Wed, 06 Aug 2003 07:39:53 GMT  
 three-part form submission using CGI.pm

 | I think that hidden() is escaping the HTML.  If so, it's arguably
 | a good feature designed to prevent special characters from screwing
 | up your form.

yes definitely, in fact I'm again calling escapeHTML() on each of the
variables I'm dumping into the resultant html output file (although I'm
not sure if I need to -- just being cautious). I was curious to notice
that unescapeHTML wasn't exported by default. *scratching head*

 | I'm not quite sure what you want to do, but I'd recommend either
 | doing a s/&#13;&#10;/<br>/ etc on the returned hidden form values (after
 | they'd been resubmitted), or else place the returned data within a
 | <pre>...</pre> block as is.

I figured out what I had to do.. what I wound up doing (and this is sort
of strange) was a broader fix_paragraphs regex sub.

whatever was happening with the hidden() params, by the time it got
there, it was *already* DOUBLED i.e. an \n in the textarea field turned
somehow into an \n\n (or something like that anyway -- there shouldn't
have been &#13;&#10;&#13;&#10; in the phase two hidden fields, but there
*was* and somehow that gets turned into FOUR of the little /\n|\r/
{*filter*}s at output  where there should only be two), and was being passed
via POST to the third sequence.. once it got there it was decoded again
before it even got to my $UT:: namespace (I checked) ... so what I wound
up doing in phase three (output phase) was this: (after much trial and
error)

sub fix_paragraphs () {
    my $fixee = shift;
    $fixee =~ s|\n\n|<br><br>|g;
    $fixee =~ s|\r\r|<br><br>|g;
    $fixee =~ s/\n|\r/<br>/g; # just in case
    $fixee =~ s/<br><br><br><br>/<br><br>/g;
    return $fixee;

Quote:
}

which works perfectly with the results sent by the

   map {
    hidden({-name=>$_, -Values=>unescapeHTML(param($_))}), "\n"
   } (param)

in phase two (validation phase)

I could probably reduce the regexes to:

    $fixee =~ s|\n\n|<br>|g;
    $fixee =~ s|\r\r|<br>|g;
    $fixee =~ s/\n|\r/<br>/g; # just in case

but it's not like it's going to eat a lot of processing for a script of
this nature, and it WILL still break up a <br> x 4 sequence that might
occur.

At least this is working now and I can move on to the rest of the
script's chunks of code. I just wish I knew why it was doubling the
paragraph returns from the textarea field. I *am* using CGI.pm 2.74, and
not an older model. *scratching head in bewilderment*

--
unmunge e-mail here:
#!perl -w
print map {chr(ord($_)-3)} split //, "zhepdvwhuCzhegudjrq1qhw";
# ( damn spammers. *shakes fist* take a hint. =:P )



Wed, 06 Aug 2003 15:42:18 GMT  
 three-part form submission using CGI.pm

Quote:
> I could probably reduce the regexes to:

>     $fixee =~ s|\n\n|<br>|g;
>     $fixee =~ s|\r\r|<br>|g;
>     $fixee =~ s/\n|\r/<br>/g; # just in case

Scott,

I suspect I'm missing a key point, but what about:

$fixee =~ s/(?:[\r\n]{2})+/<br><br>/g;
$fixee =~ s/[\r\n]/<br>/g;

Brad



Wed, 06 Aug 2003 23:10:00 GMT  
 three-part form submission using CGI.pm

Quote:

> I suspect I'm missing a key point, but what about:

> $fixee =~ s/(?:[\r\n]{2})+/<br><br>/g;

I think the on-topic part of this is that when you're reading input
from an HTTP protocol transaction (which is pretty-much analogous to
the sockets discussion in perldoc perlport) then you would do well to
binmode() the input and to do your matching on \015 and \012
(specifically CR and LF in ASCII, which are the mandated network
representations of the things you're supposed to be handling) rather
than on the logical concepts of newline and return, whose actual
representations are dependent on the programming platform.

As for the right-hand side, suffice it to say that once a line is
broken, it is broken.  Breaking it twenty times wouldn't make it any
more-broken.  But that's off-topic for this group.

all the best



Wed, 06 Aug 2003 23:43:57 GMT  
 three-part form submission using CGI.pm
In article


 | > I could probably reduce the regexes to:
 | >
 | >     $fixee =~ s|\n\n|<br>|g;
 | >     $fixee =~ s|\r\r|<br>|g;
 | >     $fixee =~ s/\n|\r/<br>/g; # just in case
 | Scott,
 |
 | I suspect I'm missing a key point, but what about:
 |
 | $fixee =~ s/(?:[\r\n]{2})+/<br><br>/g;

I haven't started experimenting with these forms yet -- does this work
under 5.004? And, am I assuming correctly, that this would obviate the
need for the final conversion, which you snipped from your response?

 | $fixee =~ s/[\r\n]/<br>/g;

but yes, I could have done it this way.

--
send mail to webmaster (at) webdragon (dot) net instead of the above address.
this is to prevent spamming. e-mail reply-to's have been altered
to prevent scan software from extracting my address for the purpose
of spamming me, which I hate with a passion bordering on obsession.  



Fri, 08 Aug 2003 22:21:16 GMT  
 three-part form submission using CGI.pm

Quote:
> In article



>  | > I could probably reduce the regexes to:
>  | >
>  | >     $fixee =~ s|\n\n|<br>|g;
>  | >     $fixee =~ s|\r\r|<br>|g;
>  | >     $fixee =~ s/\n|\r/<br>/g; # just in case
>  | Scott,
>  |
>  | I suspect I'm missing a key point, but what about:
>  |
>  | $fixee =~ s/(?:[\r\n]{2})+/<br><br>/g;

> I haven't started experimenting with these forms yet -- does this work
> under 5.004? And, am I assuming correctly, that this would obviate the
> need for the final conversion, which you snipped from your response?

Um, yes ... I think.  You'll have to try it.  But then, as a previous note
pointed out, this may not be the real issue.

Brad



Fri, 08 Aug 2003 22:50:36 GMT  
 three-part form submission using CGI.pm
In article

 | >  | $fixee =~ s/(?:[\r\n]{2})+/<br><br>/g;
 | >
 | > I haven't started experimenting with these forms yet -- does this work
 | > under 5.004? And, am I assuming correctly, that this would obviate the
 | > need for the final conversion, which you snipped from your response?
 |
 | Um, yes ... I think.  You'll have to try it.  But then, as a
 | previous note pointed out, this may not be the real issue.

ok, I'll try it on some short stuff.

as it turns out, this *was* in fact the issue, and not requiring the
other things that the respondent to which you refer was talking about.
It's the double-whammy of using a three-step single CGI script. My
biggest problem was not completely understanding what was happening to
the resultant output, which I now do (a return in the textarea field was
being converted into two somewhere during processing by CGI.pm, but via
&#13;&#10; which when converted BACK just prior to output, somehow
mysteriously becomes two \n's or two \r's ), and had coded those regexes
to catch. If your suggestions are more efficient (and can work for me
under 5.004), I believe I owe you some thanks. :)

--
unmunge e-mail here:
#!perl -w
print map {chr(ord($_)-3)} split //, "zhepdvwhuCzhegudjrq1qhw";
# ( damn spammers. *shakes fist* take a hint. =:P )



Fri, 08 Aug 2003 23:19:38 GMT  
 
 [ 16 post ]  Go to page: [1] [2]

 Relevant Pages 

1. three-part form submission using CGI.pm

2. Looking for examples using cgi.pm or form.pm

3. generating a HTML form using CGI.pm

4. CGI.pm passing hash as value from form to form

5. problem with CGI.pm and textarea in multipart/form-data forms

6. processing the Drop Down Menu (form part) using Perl script

7. Combined CGI Forms with CGI.pm

8. Three-argument form of open() and I/O disciplines

9. Three-argument form of open() and I/O disciplines

10. Printing while simultaneously using CGI.pm and Mail::Internet.pm

11. How to expire a cgi page using CGI.pm

12. Problems with http file upload using cgi.pm and cgi-lib.pl

 

 
Powered by phpBB® Forum Software