Form based Redirect

This WebDNA talk-list message is from

2001

It keeps the original formatting. numero = 40042
interpreted = N
texte = Why not submit the form to the same page and show or hide include files depending on your logic. Or submit to the same page and redirect _after_ the login is successful. The point being that all the form variables will be available within the same page without worrying about including them in a redirect.MikeOn Monday, November 12, 2001, at 10:00 AM, Donovan Brooke wrote:> hmm, yes I see what you are saying, I do this at my > checkout.html page. However, what I am talking about is on> my newaccounts setup page. Cutomers are entering new info into a > form that is being> passed back to the checkout.html page where the variables are > instantly put into a setheader context. However,> I want to have a feature on my newaccount page that has the user > enter their chosen password twice (for their> benifit) and when submitted it is varified. At this time, it has > not been added to the shopping cart because> it has been redirected to itself with the message: Your Passwords > Do Not Match. Please reenter..etc..> Even if I was to create a redundant setheader context on my > newaccounts page I would still have to pass> the variables in the redirect to itself.>> I suppose I could have a showif on my checkout page that verifies > the two passwords and redirects> back to the accounts page after first linking the variables with > the setheader context and then finds that> the two passwords are not the same. At this point wouldn't> I just open up an orderfile tag on my accounts page to repopulate > the form? I thought I read somewhere> that showcart was a dangerous tag. ???>> Brians Idea seems like it would work also but which is more > appropriate for this situation? that is the question> I guess. It doesn't seem like a lot of code to add to my > checkout.page to verify the passwords then> redirect to the account page (using ?cart=[cart]) if it is not > the same. However, it might be a good filter to NOT have the> customer info> sent to a shopping cart before the passwords are verified. I can > see kids and such creating> a new account and just typing in junk and any sort of wall at that > point might eliminate at least some false data in> the customers.db.>> Thanks much for the input.>> Donovan>>>> John Peacock wrote:>>> Donovan Brooke wrote:>>>>>> Well that would be fine but this info will be for a >>> user-interaction based module>>> (as well as a user/login to auto populate shipping/billing info).>>> Users (account holders) will be able to see past orders, place >>> reorders and see their personal>>> info and edit it if they like. So I need to store this info in a >>> customer database.>>> (sorry I didn't give the full description in the first place) >>> Even though I can't>>> pass all the variables I can pass the most needed ones which >>> might be fine for now.>>> I will take a look at Java solutions down the road to complete >>> it though.>>> thanks.>>>> Nothing you say precludes using a ShoppingCart to store the >> information, even>> if it means the user logs in with their account number and the >> next page takes>> the information in the customers.db and copies it to the >> ShoppingCart. Once>> in a cart, you only need to add ?cart=[cart] to any redirects.>>>> Think of the ShoppingCart as storing the current session >> information each time>> that they connect, and the customers.db contains their history of >> interactions>> with the site.>>>> John>>>> -->> John Peacock>> Director of Information Research and Technology>> Rowman & Littlefield Publishing Group>> 4720 Boston Way>> Lanham, MD 20706>> 301-459-3366 x.5010>> fax 301-429-5747>>>>>> -- Donovan D. Brooke> Systems Administrator/> Assc. Art Director> Epsen Hillmer Graphics>>>-------------------------------------------------------------This message is sent to you because you are subscribed to the mailing list .To unsubscribe, E-mail to: To switch to the DIGEST mode, E-mail to Web Archive of this list is at: http://search.smithmicro.com/ Associated Messages, from the most recent to the oldest:

Re: Form based Redirect (Donovan Brooke 2001)
Form based Redirect (Michael Davis 2001)
Re: Form based Redirect (John Peacock 2001)
Re: Form based Redirect (Donovan Brooke 2001)
Re: Form based Redirect (John Peacock 2001)
Re: Form based Redirect (Brian Fries 2001)
Re: Form based Redirect (Donovan Brooke 2001)
Re: Form based Redirect (Sally Reidy 2001)
Re: Form based Redirect (John Peacock 2001)
Re: Form based Redirect (Will Starck 2001)
Re: Form based Redirect (Donovan Brooke 2001)
Re: Form based Redirect (John Peacock 2001)
Re: Form based Redirect (dale 2001)
Form based Redirect (Donovan Brooke 2001)

Why not submit the form to the same page and show or hide include files depending on your logic. Or submit to the same page and redirect _after_ the login is successful. The point being that all the form variables will be available within the same page without worrying about including them in a redirect.MikeOn Monday, November 12, 2001, at 10:00 AM, Donovan Brooke wrote:> hmm, yes I see what you are saying, I do this at my > checkout.html page. However, what I am talking about is on> my newaccounts setup page. Cutomers are entering new info into a > form that is being> passed back to the checkout.html page where the variables are > instantly put into a setheader context. However,> I want to have a feature on my newaccount page that has the user > enter their chosen password twice (for their> benifit) and when submitted it is varified. At this time, it has > not been added to the shopping cart because> it has been redirected to itself with the message: Your Passwords > Do Not Match. Please reenter..etc..> Even if I was to create a redundant setheader context on my > newaccounts page I would still have to pass> the variables in the redirect to itself.>> I suppose I could have a showif on my checkout page that verifies > the two passwords and redirects> back to the accounts page after first linking the variables with > the setheader context and then finds that> the two passwords are not the same. At this point wouldn't> I just open up an orderfile tag on my accounts page to repopulate > the form? I thought I read somewhere> that showcart was a dangerous tag. ???>> Brians Idea seems like it would work also but which is more > appropriate for this situation? that is the question> I guess. It doesn't seem like a lot of code to add to my > checkout.page to verify the passwords then> redirect to the account page (using ?cart=[cart]) if it is not > the same. However, it might be a good filter to NOT have the> customer info> sent to a shopping cart before the passwords are verified. I can > see kids and such creating> a new account and just typing in junk and any sort of wall at that > point might eliminate at least some false data in> the customers.db.>> Thanks much for the input.>> Donovan>>>> John Peacock wrote:>>> Donovan Brooke wrote:>>>>>> Well that would be fine but this info will be for a >>> user-interaction based module>>> (as well as a user/login to auto populate shipping/billing info).>>> Users (account holders) will be able to see past orders, place >>> reorders and see their personal>>> info and edit it if they like. So I need to store this info in a >>> customer database.>>> (sorry I didn't give the full description in the first place) >>> Even though I can't>>> pass all the variables I can pass the most needed ones which >>> might be fine for now.>>> I will take a look at Java solutions down the road to complete >>> it though.>>> thanks.>>>> Nothing you say precludes using a ShoppingCart to store the >> information, even>> if it means the user logs in with their account number and the >> next page takes>> the information in the customers.db and copies it to the >> ShoppingCart. Once>> in a cart, you only need to add ?cart=[cart] to any redirects.>>>> Think of the ShoppingCart as storing the current session >> information each time>> that they connect, and the customers.db contains their history of >> interactions>> with the site.>>>> John>>>> -->> John Peacock>> Director of Information Research and Technology>> Rowman & Littlefield Publishing Group>> 4720 Boston Way>> Lanham, MD 20706>> 301-459-3366 x.5010>> fax 301-429-5747>>>>>> -- Donovan D. Brooke> Systems Administrator/> Assc. Art Director> Epsen Hillmer Graphics>>>-------------------------------------------------------------This message is sent to you because you are subscribed to the mailing list .To unsubscribe, E-mail to: To switch to the DIGEST mode, E-mail to Web Archive of this list is at: http://search.smithmicro.com/ Michael Davis

DOWNLOAD WEBDNA NOW!

Form based Redirect

2001

Top Articles:

Related Readings: