RE: [PHPLIB] ye`ol back button and forms From: Bob Strouper (bobw123 <email protected>)
Date: 01/05/00

Bob,

Well, since my application is for an *intranet-like* site
I decided to use javascript and open up a new window for
every new transaction ( db insert, update ...etc).
I have a MAIN window and a Tranaction window.
The main window opens up the transaction window and the
transaction window closes when the operation is done.

This transaction window has no features:
e.g: directories=no, location=no, menubar=no,
scrollbars=yes, status=no, resizable=no etc.

And the Transaction window has very little navigation...
since it is basically a form window and its sole purpose
it to perform the database queries decribed above.

see my post to the phplist:
re-using old sid (after timeout)
in the searchable mailing list archives:
http://www.progressive-comp.com/Lists/?l=phplib&r=1&w=2#phplib

Even though this is not full proof ( the user can use
Browser Hot_keys or the right mouse button to go back
etc ) this is good enough for me for my current application.

Other people have posted *solutions* for the cache problems
and the *missing* forms on BACK, such as have every insert
be an update ( by inserting a an ID and then moving away
from that page that inserts the ID with header redirection
and then performing updated on that ID ).

I think that there is basically no real solution to this
problem, I've checked out the shopping websites that
have been submitted to phlib for evaluation and they also
break on the BACK button... so maby my solution is the only
one.

Also you could go into session.inc and play with cacheing
in the function put_headers() and see if you could come up
with something better... but I belive that it is just
about impossible to have cacheing that will work across
all browers and all versions.

Bob

------Original Message------
From: "Bob Pearson" <pearson <email protected>>
To: bobw123 <email protected>
Sent: January 5, 2000 7:38:43 PM GMT
Subject: RE: [PHPLIB] ye`ol back button and forms

This message was sent from Geocrawler.com by "Bob Pearson"
<pearson <email protected>>

I don't have a solution, but I would like to emphasize your
question since I'm facing the same dilemna. Disallowing cache
is the obvious solution from the programmer perspective because
offers untainted data; however, making software for the web isn't
about what works best for us, rather what is accessible to the
average user. Many users have probably just figured out how to
use 'Back', there's a good chance that taking it away would be a
big turn off. I use it all the time to see where I've been. There
has to be a solution that satisfies all parties.

Perhaps it would be useful to be able to selectively designate
cache headers for different pages. That way only the more sensitive
pages would need to disallow cache. This can be done with PHP, but
not very readily with PHPLIB. Or maybe using a timed cache as
people have mentioned would be a solution.

I would just like to hear some varying thoughts on this. I hope someone
comes across this.

Bob Pearson

---------------------------------------
hello,

There must be a suitable solution to users clicking
the back button after ( or during ) a form submission.

As we all know, many users will not stop using the back
button just if we ask them to , so where do we go from here?

Of course the ideal phplib cache seeting is "no" as we want
to keep state in such transactions as forms which
update/edit databases.

But, Netscape somtimes cannot even find the form, when hitting
the back button ( it errs with messages like "cannot find file
/path/to/NSform.tmp" ) and IE will always attempt to reload the
form.

So what is the solution? Do we use javascript to open up a
new window without the navigational bar? Do we make every
transaction an update? do we somehow tell the script that
it`s a reload and do things accordingly ( but this would
still not fix the problem with netscape loosing the form file
alltogether )

I`ve also experimented with diabling phplibs cache
handling alltogether and then ( as someone on this list
suggested ) have all transactions UPDATES ..so if the user
hits the back button and then starts editing the same form
again, he is just screwing with the same record.

So, I wonder how the big boys do it? Honestly, I haven`t
gone to many shopping sites ( I say shopping sites, not
because this is what I`m doing , but because I think, they
may be the best way to see how someone is using db tranactions
through a web/form interface ) , they must deal with this
problem in an elegent way.

I look forward to all your comments, and what methods you have
come to use. I`m thinking, opening up a new window apon
authentication, and creating my own navigation might be the
only way to truly contole things.

Bob

______________________________________________
FREE Personalized Email at Mail.com
Sign up at http://www.mail.com?sr=mc.mk.mcm.tag001

-
PHP3 Base Library Mailing List. Send messages to <phplib <email protected>>.
To unsubscribe, send "unsubscribe" to <phplib-request <email protected>> in
the body, not the subject, of your message.

Geocrawler.com - The Knowledge Archive

______________________________________________
FREE Personalized Email at Mail.com
Sign up at http://www.mail.com?sr=mc.mk.mcm.tag001

-
PHP3 Base Library Mailing List. Send messages to <phplib <email protected>>.
To unsubscribe, send "unsubscribe" to <phplib-request <email protected>> in
the body, not the subject, of your message.