location.href--what am i doing wrong?
David Goldstein
I am new to this group and have a question that I am sure one of you JS
experts can quickly help me with. I have a login page that calls a php
script to verify that the user exists. If the user exists, the value
returned is "success" and the user should be directed to a member page.
Well, everything is working except for the redirect. Here is the code in
question:
--------------------------------------------------------
function updatePage() {
if (xmlHttp.readyState == 4) {
var response = xmlHttp.responseText;
if (response == "success") {
alert(response+"! member exists");
window.location.href = "../memberPage.php";
return false;
} else {
document.getElementById("testDiv").value = response;
alert(response);
}
}
}
-----------------------------------------------------------
I have tried location.href and window.location.href, however, nothing is
working. The value being returned is correct and the alert box displays
with the success message. The next line does not execute, however.
Thank you in advance,
David
Stefan Weiss
> function updatePage() {
> if (xmlHttp.readyState == 4) {
> var response = xmlHttp.responseText;
> if (response == "success") {
> alert(response+"! member exists");
> window.location.href = "../memberPage.php";
> return false;
> } else {
> document.getElementById("testDiv").value = response;
> alert(response);
> }
> }
> }
> -----------------------------------------------------------
>
> I have tried location.href and window.location.href, however, nothing is
> working. The value being returned is correct and the alert box displays
> with the success message. The next line does not execute, however.
How can you be sure of that? A script doesn't just stop in the middle
for no reason. Did you see any runtime error messages? Which browser
"does not execute" the location.href line? Will an alert() in the line
below that be displayed? Are frames or iframes involved?
From what I can see, your code looks OK. If it doesn't work as expected,
there ought to be some kind of message or feedback. Try running it in
Firefox with the Firebug add-on enabled (or use a similar debugger in
your browser of choice).
cheers,
stefan
Hans-Georg Michna
> window.location.href = "../memberPage.php";
David,
are the two dots really good? Try the full path for a test.
Hans-Georg
Sam Kang
> returned is "success" and the user should be directed to a member page.
> Well, everything is working except for the redirect.
> if (response == "success") {
Are you sure your servlet is returning only the string "success"? Without "\n"
or "\r" oder "\r\n"? In that case you can't compare the response. Try a
replacement of leading and trailing white spaces. i.e.
if (response.replace(/^\s+/, '').replace(/\s+$/, '') == "success")
or similar.
Did you checked it with a debugger?
Sam
--
Sufficiently advanced incompetence is indistinguishable from malice
(J. Porter Clark)
David Goldstein
news:hdhiuf$qee$1...@aioe.org...
Thanks to all who suggested a solution. I feel like an idiot, but I will
explain what happened :-0 The page being called is checking for a PHP
session variable that the user actually logged in. If the user did not log
in, he is sent to the index page. Well, the string that I was checking for
on the member page ("TRUE") was spelled differently than the string that I
had passed ("true").
I figured out the problem when I tried to go directly to the memberPage
and was immediately sent to the index page. Everything was working as it
should, so, I checked that the session variable was spelled correctly and
then saw that I checked against an incorrect spelling :-(((
There were no error messages, since the JS, and the PHP script were both
doing what they were supposed to do. I guess I should be mire careful when
programming late in to the evening.
Again, thanks to all for their positive feedback.
David
Hans-Georg Michna
> if (response.replace(/^\s+/, '').replace(/\s+$/, '') == "success")
If you want to remove whitespace, at least do it efficiently:
if (response.replace(/^\s+|\s+$/g, "") === "success") ...
I doubt though that this is actually the problem.
Hans-Georg
Stefan Weiss
> On Fri, 13 Nov 2009 00:22:22 +0100, Sam Kang wrote:
>
>> if (response.replace(/^\s+/, '').replace(/\s+$/, '') == "success")
>
> If you want to remove whitespace, at least do it efficiently:
>
> if (response.replace(/^\s+|\s+$/g, "") === "success") ...
Efficience is relative. There are too many variables here to make an
assertion like that without stating your test environments: browser,
platform, string length, amount of leading whitespace, amount of
trailing whitespace, ...
Your version tends to be a little faster with short strings and no
leading or trailing whitespace, and a little slower otherwise. Steven
Levithan has a nice comparison of various string trim implementations:
<http://blog.stevenlevithan.com/archives/faster-trim-javascript>
cheers,
stefan
Evertjan.
Efficiently?
Try:
if (/^\s*success\s*$/.test(response)) ....
--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)
Hans-Georg Michna
>Hans-Georg Michna wrote on 14 nov 2009 in comp.lang.javascript:
>> If you want to remove whitespace, at least do it efficiently:
>>
>> if (response.replace(/^\s+|\s+$/g, "") === "success") ...
>Efficiently?
>
>Try:
>
>if (/^\s*success\s*$/.test(response)) ....
Ah, great! I overlooked that.
It has happened to me time and again that I improved some
JavaScript code, only to find later that it could be improved
even more. So how about this?
if (/success/.test(response)) ...
Of course this works only if you can be sure that no other
possible response contains "success", which is very likely,
however. (:-)
Hans-Georg
Hans-Georg Michna
Stefan,
interesting link, thanks! I honestly wouldn't have guessed that
the much longer chained methods construct could be faster under
certain circumstances.
However, it looks a bit strange to me to write non-intuitively
mixed code, just to slice a few percent off the execution time
in current implementations. Browsers get new versions in quick
successions, and you cannot be sure that the new ones behave
identically. I hope particularly that regular expression engines
work very efficiently.
You also didn't cover the change from == to ===, which may well
do more than compensate for the slightly lower speed of the
different regular expression solutions. I haven't measured it
though.
By "efficient" I didn't just mean better execution time. I also
meant the efficient use of available constructs by the
programmer, i.e. shorter, simpler, easier-to-understand program
code. If you use regular expressions, for example, then you
should use them fully, rather than picking out one capability,
like ^s+, but leave out another, like |, only to replace it with
a longer JavaScript construct like chained methods.
But I sense that this is endlessly debatable, and I don't want
to get into that. So please take the above just as my personal
opinion. Everybody take his favorite pick, please. (:-) In any
case I've learned something from your message, Stefan. Thanks!
Hans-Georg
Evertjan.
I don't think that argument is valid, or you could do:
if (/ucce/.test(response))
if you can be sure that no other
possible response contains "ucce", which is very likely,
if all the other options do not include success or part of that word.
However
response = 'sorrynosuccess';
id not an unlikely alternative.
Hans-Georg Michna
>Hans-Georg Michna wrote on 15 nov 2009 in comp.lang.javascript:
>> if (/success/.test(response)) ...
>>
>> Of course this works only if you can be sure that no other
>> possible response contains "success", which is very likely,
>> however. (:-)
>I don't think that argument is valid, or you could do:
>
>if (/ucce/.test(response))
>
>if you can be sure that no other
>possible response contains "ucce", which is very likely,
>if all the other options do not include success or part of that word.
Seems to be valid. What you write is true.
>However
>
>response = 'sorrynosuccess';
>
>id not an unlikely alternative.
Funny discussion. (:-) Obviously the programmer has to know
which responses can occur.
Hans-Georg