Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Perl > Perl Misc > CGI, multiple page data input.

Reply
Thread Tools

CGI, multiple page data input.

 
 
Justin C
Guest
Posts: n/a
 
      10-18-2010
All of my web stuff (inhouse) until now has passed previously input data
back to the browser in hidden form fields when more data needs to be
collected. For example, my script that calculates shipping rates for
customer orders collects weight, number of items, country of destination
on the first page. When this page is submitted a new page is returned
asking for the dimensions of each box, this second page form is
dependent on input from the first page (each box can be different
dimensions), but I also need some of the original page's input for my
calculations later, so the original data is passed back in hidden form
fields.

I'd like to move my coding forward a little and find a better way. I'm
guessing the cookies is the correct way to progress with this, but I
want to be sure, or hear of other ways before I commit to a cookies
approach for my new web-page.

Any suggestions of reading matter, or other ways of doing this, ... am I
barking up the wrong tree? Or just barking?!

Thanks for your suggestions.

Justin.
 
Reply With Quote
 
 
 
 
Mathematisch
Guest
Posts: n/a
 
      10-18-2010

> Any suggestions of reading matter, or other ways of doing this, ... am I
> barking up the wrong tree? Or just barking?!


Try using: CGI::Session

Regards, F
 
Reply With Quote
 
 
 
 
Jürgen Exner
Guest
Posts: n/a
 
      10-18-2010
Justin C <(E-Mail Removed)> wrote:
>All of my web stuff (inhouse) until now has passed previously input data
>back to the browser in hidden form fields when more data needs to be
>collected. For example, my script that calculates shipping rates for
>customer orders collects weight, number of items, country of destination
>on the first page. When this page is submitted a new page is returned
>asking for the dimensions of each box, this second page form is
>dependent on input from the first page (each box can be different
>dimensions), but I also need some of the original page's input for my
>calculations later, so the original data is passed back in hidden form
>fields.
>
>I'd like to move my coding forward a little and find a better way. I'm
>guessing the cookies is the correct way to progress with this, but I
>want to be sure, or hear of other ways before I commit to a cookies
>approach for my new web-page.


You are looking for sessions.

Of course this has nothing to do with Perl whatsoever because the
concept of sessions is totally independent of whatever programming
language you happen to be using to implement them.

jue
 
Reply With Quote
 
Xho Jingleheimerschmidt
Guest
Posts: n/a
 
      10-19-2010
Justin C wrote:
> All of my web stuff (inhouse) until now has passed previously input data
> back to the browser in hidden form fields when more data needs to be
> collected. For example, my script that calculates shipping rates for
> customer orders collects weight, number of items, country of destination
> on the first page. When this page is submitted a new page is returned
> asking for the dimensions of each box, this second page form is
> dependent on input from the first page (each box can be different
> dimensions), but I also need some of the original page's input for my
> calculations later, so the original data is passed back in hidden form
> fields.


As long as the data is not meaningfully subject to falsification, or is
revalidated at each stage, this is quite fine.

> I'd like to move my coding forward a little and find a better way. I'm
> guessing the cookies is the correct way to progress with this, but I
> want to be sure, or hear of other ways before I commit to a cookies
> approach for my new web-page.


It is not clear to me that the direction you indicate is a 'forward'
direction.

Xho
 
Reply With Quote
 
Justin C
Guest
Posts: n/a
 
      10-19-2010
On 2010-10-18, Mathematisch <(E-Mail Removed)> wrote:
>
> Try using: CGI::Session


Thank you. I have the documentation for this open and it looks
interesting. It looks like a whole new can of worms compared with my
very basic web programming.

Justin.
 
Reply With Quote
 
Justin C
Guest
Posts: n/a
 
      10-19-2010
On 2010-10-18, Jürgen Exner <(E-Mail Removed)> wrote:
> Justin C <(E-Mail Removed)> wrote:
>>All of my web stuff (inhouse) until now has passed previously input data
>>back to the browser in hidden form fields when more data needs to be
>>collected. For example, my script that calculates shipping rates for
>>customer orders collects weight, number of items, country of destination
>>on the first page. When this page is submitted a new page is returned
>>asking for the dimensions of each box, this second page form is
>>dependent on input from the first page (each box can be different
>>dimensions), but I also need some of the original page's input for my
>>calculations later, so the original data is passed back in hidden form
>>fields.
>>
>>I'd like to move my coding forward a little and find a better way. I'm
>>guessing the cookies is the correct way to progress with this, but I
>>want to be sure, or hear of other ways before I commit to a cookies
>>approach for my new web-page.

>
> You are looking for sessions.


Yes, I see that now.


> Of course this has nothing to do with Perl whatsoever because the
> concept of sessions is totally independent of whatever programming
> language you happen to be using to implement them.


ISWYM... now I know what it is that that I'm asking!

Justin.
 
Reply With Quote
 
Justin C
Guest
Posts: n/a
 
      10-19-2010
On 2010-10-19, Justin C <(E-Mail Removed)> wrote:
> On 2010-10-18, Jürgen Exner <(E-Mail Removed)> wrote:
>> Justin C <(E-Mail Removed)> wrote:
>>>All of my web stuff (inhouse) until now has passed previously input data
>>>back to the browser in hidden form fields when more data needs to be
>>>collected. For example, my script that calculates shipping rates for
>>>customer orders collects weight, number of items, country of destination
>>>on the first page. When this page is submitted a new page is returned
>>>asking for the dimensions of each box, this second page form is
>>>dependent on input from the first page (each box can be different
>>>dimensions), but I also need some of the original page's input for my
>>>calculations later, so the original data is passed back in hidden form
>>>fields.
>>>
>>>I'd like to move my coding forward a little and find a better way. I'm
>>>guessing the cookies is the correct way to progress with this, but I
>>>want to be sure, or hear of other ways before I commit to a cookies
>>>approach for my new web-page.

>>
>> You are looking for sessions.

>
> Yes, I see that now.


Jurgen, I did mean to say thank you at this point, it was not my
intention to be as rude as the above looks. Sorry, and thank you for
your suggestion.

Justin.
 
Reply With Quote
 
Justin C
Guest
Posts: n/a
 
      10-20-2010
On 2010-10-19, Xho Jingleheimerschmidt <(E-Mail Removed)> wrote:
> Justin C wrote:
>> All of my web stuff (inhouse) until now has passed previously input data
>> back to the browser in hidden form fields when more data needs to be
>> collected. For example, my script that calculates shipping rates for
>> customer orders collects weight, number of items, country of destination
>> on the first page. When this page is submitted a new page is returned
>> asking for the dimensions of each box, this second page form is
>> dependent on input from the first page (each box can be different
>> dimensions), but I also need some of the original page's input for my
>> calculations later, so the original data is passed back in hidden form
>> fields.

>
> As long as the data is not meaningfully subject to falsification, or is
> revalidated at each stage, this is quite fine.
>
>> I'd like to move my coding forward a little and find a better way. I'm
>> guessing the cookies is the correct way to progress with this, but I
>> want to be sure, or hear of other ways before I commit to a cookies
>> approach for my new web-page.

>
> It is not clear to me that the direction you indicate is a 'forward'
> direction.


Xho, the problem is that in some of my programs there are many fields to
the forms (invoice lines, often they number in the hundreds), and to
add:
print hidden(-name=>'some-name', -value=>$cgi->param('some-name'));
a few hundred times is extremely ugly. There has to be a better way. But
as Jurgen mentioned, it's not a perl problem, though it can be solved
with perl.

I've looked at CGI::Session, and decided to re-invent the wheel. The
program is for internal use only and there is nothing to be gained by
users messing around with it, so I'm creating a sort of session ID that
I will pass in a hidden field, and using Storable to store/retrieve the
entire hash submitted by the browser. CGI::Session seemed overkill.

For a session ID I'm using:
my $sid = md5_hex (int(rand(99999999)));

and also using that as a file-name to store the data between http
submissions.

Thanks to all for the suggestions, they've got me to a solution to the
problem that is rather simple. I guess that I will have to learn about
real sessions should I ever make something like this available to the
world.

Justin.

--
Justin C, by the sea.
 
Reply With Quote
 
Xho Jingleheimerschmidt
Guest
Posts: n/a
 
      10-22-2010
Justin C wrote:
> On 2010-10-19, Xho Jingleheimerschmidt <(E-Mail Removed)> wrote:


>> It is not clear to me that the direction you indicate is a 'forward'
>> direction.

>
> Xho, the problem is that in some of my programs there are many fields to
> the forms (invoice lines, often they number in the hundreds), and to
> add:
> print hidden(-name=>'some-name', -value=>$cgi->param('some-name'));
> a few hundred times is extremely ugly.


Well then don't do that. Use a loop. Switching from hidden to session
isn't going to change that. You can write horrible code either way, if
you work hard at it.

And where do these hundreds of invoice lines come from? Did you make
the user enter them one by one, each into a different form element? Or
did you compute them from a more compact form of entry? If the latter,
why not just send back the compact form, and recompute the list on the
next submission?

> There has to be a better way. But
> as Jurgen mentioned, it's not a perl problem, though it can be solved
> with perl.
>
> I've looked at CGI::Session, and decided to re-invent the wheel.


Why?


> The
> program is for internal use only and there is nothing to be gained by
> users messing around with it, so I'm creating a sort of session ID that
> I will pass in a hidden field, and using Storable to store/retrieve the
> entire hash submitted by the browser. CGI::Session seemed overkill.
>
> For a session ID I'm using:
> my $sid = md5_hex (int(rand(99999999)));


Why not just use the random integer directly? Using md5 this way
doesn't make accidental collisions less likely. And since you have just
published your intentions, using an md5 doesn't make malicious ones less
likely, either.

Xho
 
Reply With Quote
 
Justin C
Guest
Posts: n/a
 
      10-27-2010
On 2010-10-22, Xho Jingleheimerschmidt <(E-Mail Removed)> wrote:
> Justin C wrote:
>> On 2010-10-19, Xho Jingleheimerschmidt <(E-Mail Removed)> wrote:

>
>>> It is not clear to me that the direction you indicate is a 'forward'
>>> direction.

>>
>> Xho, the problem is that in some of my programs there are many fields to
>> the forms (invoice lines, often they number in the hundreds), and to
>> add:
>> print hidden(-name=>'some-name', -value=>$cgi->param('some-name'));
>> a few hundred times is extremely ugly.

>
> Well then don't do that. Use a loop. Switching from hidden to session
> isn't going to change that. You can write horrible code either way, if
> you work hard at it.


Oh, I don't have to work hard, it comes perfectly naturally. I am,
however, trying to improve.


> And where do these hundreds of invoice lines come from? Did you make
> the user enter them one by one, each into a different form element? Or
> did you compute them from a more compact form of entry? If the latter,
> why not just send back the compact form, and recompute the list on the
> next submission?


The user copy/pastes. That is an idea, I shall think about it.


>> There has to be a better way. But
>> as Jurgen mentioned, it's not a perl problem, though it can be solved
>> with perl.
>>
>> I've looked at CGI::Session, and decided to re-invent the wheel.

>
> Why?


I know, makes no sense, call it a logic failure. Either I get the hang
of sessions or I don't, what I have proposed appears to fall between the
two, yes it is some kind of session management, but it isn't as robust
as 'real' session management as provided by CGI::Session.

Maybe time to think again.


>> The
>> program is for internal use only and there is nothing to be gained by
>> users messing around with it, so I'm creating a sort of session ID that
>> I will pass in a hidden field, and using Storable to store/retrieve the
>> entire hash submitted by the browser. CGI::Session seemed overkill.
>>
>> For a session ID I'm using:
>> my $sid = md5_hex (int(rand(99999999)));

>
> Why not just use the random integer directly?


Because I stupidly swiped the code from a web-site somewhere and gave no
consideration to why they were doing it that way... I still have no
idea.


> Using md5 this way
> doesn't make accidental collisions less likely. And since you have just
> published your intentions, using an md5 doesn't make malicious ones less
> likely, either.


This is purely for internal use at my employment, and I don't think
there is any way a user here could maliciously use previously uploaded
invoice data to create an invoice for customs. If they wanted to create
a false invoice it's easier to just provide the false data in the first
place.

Thank you for pointing out the errors in my thinking (or errors I make
when I don't think).

Justin.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
bind multiple data tables from sql queries to multiple datacontainers? Daves ASP .Net 1 01-06-2006 04:17 PM
Populating multiple textboxes with multiple records for update page Drew ASP General 7 11-10-2004 02:21 PM
multiple dropdown lists = multiple data readers??? Andrew Kidd ASP .Net 3 04-22-2004 03:23 PM
multiple dropdown lists = multiple data readers??? Andrew Kidd ASP .Net Web Controls 1 04-21-2004 10:36 AM
Restore added data in Data Grid in a Page When the page is reloaded krian ASP .Net 1 11-12-2003 10:06 PM



Advertisments