Making a multi-page application

[Drew]

I need to develop an application that will span 12 or so pages, and on the
last page, it lets the user review the data and then insert it all. This is
kind of like selling something on eBay, you give it information, click next,
enter more info and then at the end you review and submit the item. I was
thinking about sessions, but some of the fields are pretty big, like
varchar(5000) so I didn't know if there was a way to handle these big
fields.

Thanks,
Drew

[John]

Send the data from page1 tot page2 and store these in HIDDEN fields, then
you bring the data from the new data and the hidden date to page3 and so on.

[Drew]

I couldn't see the tree for the forest! Thanks so much for your help!

Thanks,
Drew

"John" <n o b o d [e-mail]> wrote in message
news:Xl**********************@phobos.telenet-ops.be...

Send the data from page1 tot page2 and store these in HIDDEN fields, then
you bring the data from the new data and the hidden date to page3 and so on.

[Jeff Cochran]

On Fri, 03 Sep 2004 13:30:31 GMT, "John" <n o b o d [e-mail]> wrote:

Send the data from page1 tot page2 and store these in HIDDEN fields, then
you bring the data from the new data and the hidden date to page3 and so on.

Or session variables, or update a temporary record on each page, it
depends a lot on what you're doing and why as to which you'd choose.
For example, if this was a report filled out online that would take
the user half an hour, I'd use a temporary record since I'd hate to
lose the first 8 pages when my connection dropped.

Jeff

[David C. Holley]

Or use session variables as in...

http://www.gatewayorlando.com/conten...rch_Submit.asp

David H

Drew wrote:

I couldn't see the tree for the forest! Thanks so much for your help!

Thanks,
Drew

"John" <n o b o d [e-mail]> wrote in message
news:Xl**********************@phobos.telenet-ops.be...

Send the data from page1 tot page2 and store these in HIDDEN fields, then
you bring the data from the new data and the hidden date to page3 and so

on.

[Luis]

On Fri, 03 Sep 2004 12:11:30 -0400, "David C. Holley"
<Da**********@netscape.net> wrote:

Or use session variables as in...

http://www.gatewayorlando.com/conten...rch_Submit.asp

David H

I'd stay away from session variables for what he wants to do. I took
over the development of a similar application with a number of input
screens and a "confirm" screen at the end which did a whole bunch of
calculations when it was submitted. It worked fine with most users,
but there was always some 'difficult' user who would have problems,
eg. some of the session variables on some of the screens would lose
their values and affect the calculation on the last screen. And
there's always the oddball user who refuses to enable cookies and
session variables because of the big "Microsoft conspiracy"...

The database approach ended up working better and was much more
reliable. When the user submits the first page send all the data to a
database. Then retrieve the id of the record that the user inserted.
Then use that id to update the record after each of the subsequent
screens.

If the database isn't an option, go with the hidden form fields and
querystring options. I've had success with those too...

[Evertjan.]

Luis wrote on 04 sep 2004 in microsoft.public.inetserver.asp.general:

I'd stay away from session variables for what he wants to do.

I would not.

Session variables is one of the best things of ASP, making all kinds of
user specific data available to all pages in a session, without depending
on clientside constructions that can easily be changed by the first whizkid
of the block.

If a user has his session cookie use switched of, you can politely tell him
that he cannot use the functionality offered to all other users.

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress,
but let us keep the discussions in the newsgroup)

[Jeff Cochran]

On Sat, 04 Sep 2004 16:52:56 +0200, Luis <andyza@***webmail***.co.za>
wrote:

On Fri, 03 Sep 2004 12:11:30 -0400, "David C. Holley"
<Da**********@netscape.net> wrote:

Or use session variables as in...

http://www.gatewayorlando.com/conten...rch_Submit.asp

David H

I'd stay away from session variables for what he wants to do.

Session variables in this case make more sense than hidden fields in
query strings. Also harder to spoof.

Jeff

[mark | r]

"Drew" <dl****@NOswvtc.state.va.SPAMus> wrote in message
news:uc**************@TK2MSFTNGP11.phx.gbl...

I need to develop an application that will span 12 or so pages, and on the
last page, it lets the user review the data and then insert it all. This
is
kind of like selling something on eBay, you give it information, click
next,
enter more info and then at the end you review and submit the item. I was
thinking about sessions, but some of the fields are pretty big, like
varchar(5000) so I didn't know if there was a way to handle these big
fields.

i'd do what gmail does and create one page of DIV's that are overlayed and
stepped through using document.getelementbyid(id).style.display='block' (or
'hidden')

that way you only have to have two post (at the end), no cookies, session
variables or other crap to worry about - the site loads quickly and the
final page reviews the and submits

see the "mortgage quote" page on www.123mortgagecentre.co.uk to see the DIV
script in action.

mark

[Drew]

I'm not worrying about spoofing at this point. All of this is internal, on
our intranet. I think I will try Luis' advice and insert it into the table,
or maybe I will use a tempdb for this and then insert it all into the
table...

Thanks for all the replies on this subject!
Drew

"Jeff Cochran" <je*********@zina.com> wrote in message
news:41*****************@msnews.microsoft.com...

On Sat, 04 Sep 2004 16:52:56 +0200, Luis <andyza@***webmail***.co.za>
wrote:

On Fri, 03 Sep 2004 12:11:30 -0400, "David C. Holley"
<Da**********@netscape.net> wrote:

Or use session variables as in...

http://www.gatewayorlando.com/conten...rch_Submit.asp

David H

I'd stay away from session variables for what he wants to do.

Session variables in this case make more sense than hidden fields in
query strings. Also harder to spoof.

Jeff