|
|
Posted by Jonathan N. Little on 01/24/06 00:07
Alan J. Flavell wrote:
> On Mon, 23 Jan 2006, Jonathan N. Little wrote:
>
>
>>Alan J. Flavell wrote:
>>
>>
>>>On Mon, 23 Jan 2006, Jonathan N. Little wrote:
>>>
>>>
>>>>Travis Newbury wrote:
>>>>
>>>>
>>>>>Leszek wrote:
>>>>>
>>>>>
>>>>>>I tried something like this:
>>>>>><input type="button" value="<<Back" onclick="history.back()"/>
>>>>>>and it works with my browser
>>>>>>But is the input type="button" working with all browsers?
>>>
>>>RTFM.
>>
>>Do you mean me?
>
>
> Follow the quote marks?
My error here...missed that this was in response to Leszek. Can get
confusing with quote depth.
>
>>>>The way I did it was to have one PHP script handle all pages of the
>>>>multipage form, then for each page I had two submit buttons...
>>>>
>>>>#on Page 1
>>>><input type="submit" name="back0" value="<<Back">
>>>
>>>[...]
>>>
>>
>>This has absolutely *nothing* to do with JavaScript!
>
>
> Then it's even more confusing to refer to "Back", since your
> server-side process has no real idea what's on the browser's history
> stack.
I am not referring to 'Back' akin to JavaScript history.back() method,
but a form field element named 'back0' or 'back1' or ... relating to
OP's terms of 'back' and 'next' for the labels of his buttons. 'next3'
or 'back1' seems logical enough to act as trappable flag parameters in
the query to route your PHP script. If it so pleases you the names could
have been more verbose:
#on Page 1
<input type="submit" name="returnToPage0" value="<<Back">
<input type="submit" name="goToPage2" value="Next>>">
;-)
>>Do you seen any 'onclick' or any other event handler in my example?
>
>
> Only in what you quoted, indeed.
>
>
>>Again this is server-side!
>
>
> So it seems that now the user is presented with a browser Back button
> that does one thing (that they are presumably familiar with), and an
> in-page Back control that does something that they can only guess at.
>
>
>>But just for your benefit, I do also have JavaScript that attach and
>>onclick and onsubmit handlers of *if* JavaScript is available then I
>>can pretest and catch errors *before* making a server call...
>
>
> Now he tells us...
What does it matter, the original example is server-side and work
regardless of browser settings. Mu only point was that the JavaScript
validation is only a added feature that can enhance the process but is
not dependent on the JavaScript to function properly.
>
>>Again, I chalk this all up to that you misread my post.
>
>
> Fair comment, but I took your "the way I did it was..." at face value.
> In fact, it now seems that you didn't do "it", but something different
> - which, with respect, you didn't describe in detail until I
> challenged you.
>
"the way I did it was..." comment was with respect to the OP's question
about handling backing up when processing forms with PHP. My way, (in
fact that method is what I use on my own site), is not to use JavaScript
which may or may not be available, but to use server-side scripting and
direct via parameters passed....
I outlined the process and benefits thereof, but no, I did not script it
for him. That's his job. If he has questions on specific points, I will
be happy to help, but I am not going to code his page for him.
--
Take care,
Jonathan
-------------------
LITTLE WORKS STUDIO
http://www.LittleWorksStudio.com
Navigation:
[Reply to this message]
|