[FX.php List] GET vs. POST in a web app

[Bob Patin]

Thanks for all the affirmations; you guys all echoed the sentiments  
that I had... I'm tempted to take all of the comments and forward  
them to my client... :)

I have excellent navigation in the site; there's no reason to use the  
BACK button except for sheer laziness, but you know how that is. This  
site isn't a linear site like a shopping cart, and the navigation  
will allow them to go anywhere from anywhere else, but... oh well,  
now I'll see what the client wants to do.

Thanks all,

Bob Patin
Longterm Solutions
bob at longtermsolutions.com
615-333-6858
http://www.longtermsolutions.com

   CONTACT US VIA INSTANT MESSAGING:
      AIM or iChat: longterm1954
      Yahoo: longterm_solutions
      MSN: tech at longtermsolutions.com
      ICQ: 159333060


On May 4, 2007, at 11:33 AM, Dale Bengston wrote:

> Read all the way to the end this time. ;-)
>
> I would work on navigation that reduces or eliminates the use of  
> the browser back button. I have one client with two of my sites and  
> https, and pressing the back button (IE Windows) gives the POST  
> warning followed by a blank page. Yuck! I spent a lot of time  
> working on the interface to eliminate that habit. Also, I had some  
> "cancel" buttons that used history.go(-1), which is pretty much the  
> same thing.
>
> If you have alternatives in your interface, then you have  
> ammunition to say, "Don't use the back button. Use the site  
> navigation."
>
> Dale
>
> On May 4, 2007, at 11:10 AM, Bob Patin wrote:
>
>> I'm finishing up a large project for a client whose users will be  
>> a group of hospitals and physicians. The whole project is  
>> finished--or should I say, it WAS finished--until the end client  
>> (a hospital person) noticed that using the BACK button caused the  
>> POST warning to come up, since so many pages were displaying the  
>> results of various POSTs.
>>
>> So my client asked me if I could go through the site and replace  
>> all the POSTs with GETs. I cautioned him, pointing out the fact  
>> that everything would be in the clear, including passwords, but he  
>> asked me to go forward with the change anyway.
>>
>> So I did so... and immediately saw that logins didn't work because  
>> the @ sign in emails would break the URL in a GET. I then saw that  
>> editing a user's profile, which contained email addresses, as well  
>> as possible URLs, would also not work using GETs.
>>
>> So to have an answer ready for them, here's my question: is there  
>> a way, using a GET command, to make it work with @ signs and  
>> various other special symbols that URLs use? I don't want to go  
>> down this road, but I'm anticipating their insistence on trying to  
>> make this work.
>>
>> Before you tell me, I know and agree that using GETs like this is  
>> an awful idea, but the client (the end-user) is concerned about  
>> how the BACK button causes problems. How do you guys get around  
>> this, or do you?
>>
>> Thanks,
>>
>> Bob Patin
>> Longterm Solutions
>> bob at longtermsolutions.com
>> 615-333-6858
>> http://www.longtermsolutions.com
>>
>>   CONTACT US VIA INSTANT MESSAGING:
>>      AIM or iChat: longterm1954
>>      Yahoo: longterm_solutions
>>      MSN: tech at longtermsolutions.com
>>      ICQ: 159333060
>>
>>
>> _______________________________________________
>> FX.php_List mailing list
>> FX.php_List at mail.iviking.org
>> http://www.iviking.org/mailman/listinfo/fx.php_list
>
> _______________________________________________
> FX.php_List mailing list
> FX.php_List at mail.iviking.org
> http://www.iviking.org/mailman/listinfo/fx.php_list