Fucntion to POST???
Sta12s
Javascript and PHP so my code is going to look like crap ;)
Now for my problem,
I'm trying to do a little quiz with Javascript but I would like to pass
along the varibles to a php file (for some reason I have a feeling it
would be easier)
I'm trying to gather the varibles through "onClick", but I don't know
how to use "onClick" PLUS I can't find anything helpful (rather, dumbed
down enough).
After I have collected the varibles, I would like to send them to a php
file that would give a report based on the varibles .... any
sujestions?
If you would like to see my code it's located at <a
href="http://www.kosidesigns.com/quiz">Quiz</a>
I know the page looks horrible, I'll fix dat later ...
Many thanks in advance!!
-Sta12s
VK
Sta12s wrote:
> I'm trying to do a little quiz with Javascript but I would like to pass
> along the varibles to a php file (for some reason I have a feeling it
> would be easier)
> I'm trying to gather the varibles through "onClick", but I don't know
> how to use "onClick"
If you want to keep using javascript: pseudo-protocol:
<a href="javascript:void(showSection('business'));">Yes</a>
<a href="javascript:void(showSection('nonbiz'));">No</a></p>
It has a complication on IE with animated GIF's though (namely
animation stop playing on click). You may want to leave that then and
use instead:
<a href="IfScriptIsDisabled.html"
onclick="showSection('business',this);return false;">
where "this" will refer to the link object.
*this is optional* - if you decide later to do something with the
clicked object (paint it, remove etc.)
There is a better and more often used (but more difficult) way to know
what element has been clicked by studying the event object. If you want
the cold turkey learning method, let's talk about event model and
methods.
> After I have collected the varibles, I would like to send them to a php
> file that would give a report based on the varibles .... any
> sujestions?
By staying on the same page or by replacing the current page with the
server response?
If the latter then the best would be to have a form with hidden fields
to fill step by step with user choices.
Actually you could use right away a form with fieldsets (where only one
fieldset is visible at a given moment) - instead of DIV's. That would
be even more simple.
If you want to stay on the same page upon the form submission you can
use Ajax Toolbox:
<http://www.ajaxtoolbox.com>
Sta12s
Have a great thanksgiving!!
VK
Sta12s wrote:
> Have a great thanksgiving!!
You too, man!
:-)
Sta12s
everything and b) can I just create a function that would send the
varibles (either server side or client, doesn't really matter) to a php
file that would spit out data based the the varibles?
The reason i wanted to use onClick was because I wanted to assign the
values once the person clicks on the link
i.e.
"Is this website for a business?"
yes would return "biz" and no would return "non-biz"
etc ...
I was thinking on declaring the varibles in the header and then
assigning them with "onClick" - Once then person is done with the quiz,
they then click on a button that would submit all the varibles via POST
- I just don't know how to script that function out ....
i.e.
function sendPHP(don't know what to put here???)
post data script;
then having ...
<a href="javascript:sendPHP(all my varibles here?)">Click here to get
your report</a>
Does that make any sense? LOL
Thanks
-Sarah
Oh, once again my code it at http://www.kosidesigns.com/quiz
VK
Perfect sense. As it happens very often, the same thing can be done
like this or like that or even better. I'm getting an impression that
would prefer to think about Thanksgiving now rather than learning
JavaScript in's and out's. :-)
So I'm givining the killer simple way:
<script type="text/javascript">
var userChoices = "";
// userChoices is global
// ... the rest of your script
Then on each new choice:
userChouses+= "::" + currentChoice;
// "::" or any other separator - just make sure that
// it will be not met in the choices themselve
and then finally:
<a href="javascript:void(sendPHP())">Click here to get your report</a>
where
function sendPHP() {
document.location.href =
"http://www.myserver.com/my.php?"
+ escape(userChoices);
}
VK
sorry, still should be:
window.location.href = ...
Historically window.location was read/write, and document.location
read-only.
I see that modern browsers dropped this difference, but for the
safety's sake...
Randy Webb
>>Does that make any sense?
>
>
> Perfect sense. As it happens very often, the same thing can be done
> like this or like that or even better. I'm getting an impression that
> would prefer to think about Thanksgiving now rather than learning
> JavaScript in's and out's. :-)
>
> So I'm givining the killer simple way:
> <script type="text/javascript">
> var userChoices = "";
> // userChoices is global
> // ... the rest of your script
>
> Then on each new choice:
>
> userChouses+= "::" + currentChoice;
> // "::" or any other separator - just make sure that
> // it will be not met in the choices themselve
>
> and then finally:
>
> <a href="javascript:void(sendPHP())">Click here to get your report</a>
How many times must it be told to you before it actually sinks in your
head not to use the javascript: pseudo-protocol?
If you want to submit a form, submit a freaking form. Sheesh. And for
the non-JS crowd, simply give them a form with a submit button. Onload
of the page, remove the form, implement your JS solution. It's quite
simple if you remove your head from the sand and give it some serious
thought.
--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Sta12s
VK
> How many times must it be told to you before it actually sinks in your
> head not to use the javascript: pseudo-protocol?
Unfortunately due to the limited capability of my head it doesn't sink
into it everything what people says. Before to actually sink into, the
fact has to be first proven to be:
1) factually correct
2) right to be followed (thus not leading or supporting things I'm not
agree with)
This sorry medical limitation allows though to keep the limited volume
of my brains for new things and avoid the overall dangerous "someone
said - I follow" behavior.
In this partucular question you failed to pass the first check, because
between the statement of Randy Webb and the statement of actual
JavaScript inventors and developers I'm sorry to choose the latter:
<http://devedge-temp.mozilla.org/library/manuals/2000/javascript/1.3/reference/ops.html#1042625>
But I'm totally agree that in the modern environment there is no need
anymore to use this old way and there is much better way which I
suggested in my original response.
> If you want to submit a form, submit a freaking form. Sheesh. And for
> the non-JS crowd, simply give them a form with a submit button. Onload
> of the page, remove the form, implement your JS solution. It's quite
> simple if you remove your head from the sand and give it some serious
> thought.
Dr. VK says: definitely a Bad Day.
I hope that I managed to cheer you up a bit at least in the response
above.
Randy Webb
> Randy Webb wrote:
>
>>How many times must it be told to you before it actually sinks in your
>>head not to use the javascript: pseudo-protocol?
>
>
> Unfortunately due to the limited capability of my head it doesn't sink
> into it everything what people says.
I didn't ask you to accept what I said as the Gospel Truth, it is quite
easy to test for yourself.
> Before to actually sink into, the fact has to be first proven to be:
> 1) factually correct
"factually correct" that javascript: pseudo-protocol has problems? That
has been proven, repeatedly, many many times.
> 2) right to be followed (thus not leading or supporting things I'm not
> agree with)
When you have a choice of writing code that won't fail and writing code
that is known to fail (and can be proven to fail) and you still choose
to write code that can fail, well, that is your ill-advised choice.
> This sorry medical limitation allows though to keep the limited volume
> of my brains for new things and avoid the overall dangerous "someone
> said - I follow" behavior.
Again, don't follow what I said because I said it, test it and think
about it yourself. It's not that hard a line of reasoning to follow.
> In this partucular question you failed to pass the first check, because
> between the statement of Randy Webb and the statement of actual
> JavaScript inventors and developers I'm sorry to choose the latter:
> <http://devedge-temp.mozilla.org/library/manuals/2000/javascript/1.3/reference/ops.html#1042625>
The "inventors and developers" you refer to also invented eval. Does
that mean you should use it all the time? Of course not. Why? Because
there are *better* ways to do it.
But, as for the example you quote, its utter crap.
> But I'm totally agree that in the modern environment there is no need
> anymore to use this old way and there is much better way which I
> suggested in my original response.
Then why even post a bad way to do something? Leave it be and people
will stop learning that bad habit to start with.
The only reason that 99% of this group hasn't kill-filed you is because
someone has to correct your incorrect assumptions/statements. Not in the
hope that you will learn better, but in the hopes that new people who
read it won't follow the ill advice you give at times VK.
VK
Randy Webb wrote:
> a lot of nasty stuff: see the previous post
If you'd spend some time by *reading* this thread, you would see that I
proposed the preferred way to have psi-links in the document in my
first response.
OP told me then: "Please I have this code already done and I don't have
time right now to rewrite it. Just give me a quick hack for the
existing code."
I gave him a working solution based on this demand. Do I suppose to say
"Go to hell until all code is rewritten by the group standards"? That's
not in my books. I may suggest, but I'm not trying to be a cop.
comp.lang.javascript is not the only place in the world where people
may get some knowledge (often wrong) about JavaScript. And if someone
posts here a code formatted like:
<HEAD>
<TITLE>My Page</TITLE>
<SCRIPT LANGUAGE="JavaScript"><!--
function myFunction() {
...
}
-->
</SCRIPT>
</HEAD>
it doesn't necessary mean that he did it to spoil the mood to Randy
Webb or that he's making some nasty public statement. It can be a
totally innocent Safari user who just followed the *official* (despite
wrong) recommendation of his computer producer:
<http://developer.apple.com/documentation/AppleApplications/Conceptual/SafariJSProgTopics/index.html#//apple_ref/doc/uid/TP40001483>
If you take the situation in this newsgroup so seriously you could
write some "JavaScript Validator" and post a link here on a weekly
basis like FAQ.
Validation should do:
script language => script type
<!-- //--> => remove
document.all => document.getElementById
eval => auto insert a comment above /* I know it is very bad but I did
not find yet a better way */
href="javascript:myFunction()" => href="noScript.html"
onclick="myFunction();return false;"
This rather primitive parsing script could be done long time ago
actually and it would make clj much more friendly. Do you want to
volunteer? I can help a bit under your direction.
Richard Cornford
<snip>
> <a href="javascript:void(showSection('business'));">Yes</a>
> <a href="javascript:void(showSection('nonbiz'));">No</a></p>
>
> It has a complication on IE with animated GIF's though
> (namely animation stop playing on click). You may want
> to leave that then and use instead:
If the issues arising from the activation of a javascript
pseudo-protocol HREF where restricted to the displaying of animated GIF
images that would be the advice given. Instead the advice is that
following the activation of a javascript pseudo-protocol HREF all bets
are off as to what facilities will remain available to javascript. The
limits of the problems have not been determined (mostly because the
individual best able to analyse script issues have long since abandoned
the practice entirely) but they are wide ranging, no matter what you may
prefer to believe.
You may prefer to keep your head buried in the sand so you cannot see
the precession of questions about problems that are restricted to IE and
commence at the moment of the activation of a javascript HREF but those
questions do appear. There have been at least 4 in the last 4 months,
and that is a lower rate than over the preceding years (probably because
he advice never to use the javascript pseudo protocol for anything that
does not directly replace the current document is sinking in).
Another example:-
----------------------- pseudoTest.html -----------------------------
<html>
<head>
<title>javascript pseudo-protocol in IE test</title>
<meta http-equiv="refresh" content="10; url=pseudoTest.html">
<script type="text/javascript">
var field;
var loadTime = (new Date()).getTime();
function init(){
field = document.forms['f'].elements['t'];
showTime();
setInterval(showTime, 100);
}
function showTime(){
field.value = (((new Date()).getTime() - loadTime)/1000);
}
</script>
</head>
<body onload="init()">
<form action="" onsubmit="return false;" name="f">
<input type="text" vlaue="" name="t" size="20">
</form>
<a href="javascript:void 0;">javascript:void 0;</a>
</body>
</html>
Load it into IE, watch the counter count to 10 ish and the page will
re-load due to the MTA refresh (assuming scripting and META refresh are
enabled), the counter then counts up to 10 ish again and the page
refreshes, and so on. Until you click the javascript link, when the
counter keeps counting but the page never refreshes again.
No try dismissing that as a rendering bug.
Activating javascript pseudo-protocol links puts IE into a different
'state', pending the anticipate replacement of the page following what
the browser perceives as navigation. In this waiting state the browser
stops doing some of the things that it would normally do and facilities
cease to be available to scripting. This is evident enough to convince
the rational that never using a javascript HREF is a sensible strategy
for avoiding any consequential issues.
Richard.
VK
Richard Cornford wrote:
> If the issues arising from the activation of a javascript
> pseudo-protocol HREF where restricted to the displaying of animated GIF
> images that would be the advice given. Instead the advice is that
> following the activation of a javascript pseudo-protocol HREF all bets
> are off as to what facilities will remain available to javascript. The
> limits of the problems have not been determined (mostly because the
> individual best able to analyse script issues have long since abandoned
> the practice entirely) but they are wide ranging, no matter what you may
> prefer to believe.
God damn cries it!
<a href="noScript.html" onclick="myFunction();return false;">My
link</a> is the BEST and the only one CLINICALLY UPPROVED way to call
JavaScript function from a link. Dito!
I said it once in this thread, I said it twice, I can put an epitimia
on myself if you want to - to post the above statement every week in
this group.
I explained WHY I did not change the whole script: because neither I
nor the OP had no time and NO IDEA of terrible consequences of even
occasional using of "javascript:" while posting your code in
comp.lang.javascript.
Richard Cornford
> Richard Cornford wrote:
<snip>
>> ... the advice is that following the activation of a
>> javascript pseudo-protocol HREF all bets are off as to
<snip>
> I said it once in this thread, I said it twice, I can put an
> epitimia on myself if you want to - to post the above statement
> every week in this group.
You posted code that demonstrates the use of a formulation that is known
to be directly harmful and completely unnecessary. In doing that you are
potentially doing harm to others.
> I explained WHY I did not change the whole script: because
> neither I nor the OP had no time and NO IDEA of terrible
> consequences of even occasional using of "javascript:" while
> posting your code in comp.lang.javascript.
If you have no idea of the consequences then that is your fault as you
have been told repeatedly what the situation is. Your only reason for
not knowing is your own unwillingness to believe either the information
or the demonstrations.
What the OP knows is uncertain, but whatever that is you can be fairly
sure that they don't want to be sent off down a blind alley that ends
with a manifestation of a javascript pseudo-protocol related issue and
then have to do a lot of extra work re-tracing their steps. It is much
better to demonstrate only the alternative that does not introduce extra
issues and let them potentially never encounter the problems.
Richard.
VK
Richard Cornford wrote:
> You posted code that demonstrates the use of a formulation that is known
> to be directly harmful and completely unnecessary. In doing that you are
> potentially doing harm to others.
> have been told repeatedly what the situation is. Your only reason for
> not knowing is your own unwillingness to believe either the information
> or the demonstrations.
> What the OP knows is uncertain, but whatever that is you can be fairly
> sure that they don't want to be sent off down a blind alley that ends
> with a manifestation of a javascript pseudo-protocol related issue and
> then have to do a lot of extra work re-tracing their steps. It is much
> better to demonstrate only the alternative that does not introduce extra
> issues and let them potentially never encounter the problems.
Richard,
Are you going anywhere in the Internet besides clj? People just doing
what they see on the major web-sites where <a
href="javascript:someFunction()" became a standard de-facto (even w/o
traditional void() wrapper!).They see it in Hotmail,CNN, MSN, Yahoo...
It is not totally correct, it is not academically approved, there are
better ways: but rather often people wants and chooses what is more
convenient and not what is more correct. (think of innerHTML). A bunch
of lasy uneducated amateurs, I know ;-)
But you cannot just keep screaming on anyone that Hotmail, MSN or Yahoo
have no idea about web-development and only few "selected" people in
clj have it. Most of the time you'll get just a homorious effect. Keep
suggecting, but do not go ballistic over it.
Or even better - let's make a JavaScript-written JavaScript Validator
as I suggested in this thread and post it together with FAQ's
This way one can simply say: "Please pass you sample code through the
validator, it is to difficult to read it as it is".
And every 3rd new post would not be lost then in the endless "- The
script tag is wrong, comments are unnecessary. - But why my script is
not working? - Change your links. - But why it's not working? - DTD
declaration is missing. - But... - Do what I said, you bastard!"
Randy Webb
> Randy Webb wrote:
>
>>a lot of nasty stuff: see the previous post
>
>
> If you'd spend some time by *reading* this thread, you would see that I
> proposed the preferred way to have psi-links in the document in my
> first response.
How do you think I knew you proposed it at all? I have read this thread,
and more than once. But giving bad advice, in any case, is always bad.
<snip>
> comp.lang.javascript is not the only place in the world where people
> may get some knowledge (often wrong) about JavaScript.
There is no doubt at all that some people, who will remain nameless,
continue to give "often wrong" advice in this group even after it is
shown to them that the advice was wrong.
> And if someone posts here a code formatted like:
>
> <HEAD>
> <TITLE>My Page</TITLE>
> <SCRIPT LANGUAGE="JavaScript"><!--
>
> function myFunction() {
> ...
> }
> -->
> </SCRIPT>
> </HEAD>
>
> it doesn't necessary mean that he did it to spoil the mood to Randy
> Webb or that he's making some nasty public statement.
I have never said otherwise.
> It can be a totally innocent Safari user who just followed the *official*
> (despite wrong) recommendation of his computer producer:
> <http://developer.apple.com/documentation/AppleApplications/Conceptual/SafariJSProgTopics/index.html#//apple_ref/doc/uid/TP40001483>
"Official" from the manufacturer, maybe, but not "official" from any
group that actually has even the slightest ability to give an "official"
recomendation, but your point is made.
The problem I personally have with people replying to code like the
above is when they reply simply to say "use the type attribute, don't
hide scripts...." but don't bother to even attempt to answer the
question. Now those are annoying and a waste of time.
> If you take the situation in this newsgroup so seriously you could
> write some "JavaScript Validator" and post a link here on a weekly
> basis like FAQ.
> Validation should do:
>
> script language => script type
That should be trivial. Read the script tag, search for language, search
for type, act accordingly. But, do not correct it, give notes to the
user of what is wrong so that they actually learn. And not notes like
the W3C validator, it's messages are cryptic at best.
> <!-- //--> => remove
> document.all => document.getElementById
Simple indexOf( search for document.all, but, you can not simply replace
them. document.all does not behave the same exact way as gEBI.
> eval => auto insert a comment above /* I know it is very bad but I did
> not find yet a better way */
Not sure that is 100% fail proof either because there are actually some
scenarios where eval is the best way.
> href="javascript:myFunction()" => href="noScript.html"
> onclick="myFunction();return false;"
That, to me, falls more into HTML validation that script validation as
its an HTML issue.
Maybe Douglas could add it to JSLint at
<URL: http://www.crockford.com/jslint/index.html>
> This rather primitive parsing script could be done long time ago
> actually and it would make clj much more friendly. Do you want to
> volunteer? I can help a bit under your direction.
--
Sta12s
ANYHOOS .... After trying my butt off to figure out how the hell to get
this stuff to work;
a. VK, I'm so sorry but that code you gave me didn't work - I tweaked
the hell out of it and I think I might have invented a new language (I
call it XpressoScript ;) but it didn't work never the less
b. I took Jack Ass's advice about the form - just use a phreakin form
if you want to submit a form - well jack, that shiz doesn't work either
...
So here is my problem - I have DIV's, that's the only thing I can think
of. I have tested everything from my PHP on my server to my pages
themselves ... the div's are ruining my cute little quiz page!
I tried declaring all my values before sending them through the form -
nope
I tried making a function that would send the values - nope
I tried sending the values through the header - nope
The weird thing is when I tried sending through the header to a php
file nothing would show up past the ? - didn't matter if it was in ()
or "" or if I had escape() ...
By the way Jack - I figured out the onclick=java blah blah on my own -
not from reading your rant ... not all of us newb's are retards ;P
VK
(or even better to give us a link)
And do not take this discussion to close to your heart - that's an
ever-lasting buttle, you just happened to stay on the way ;-)
Sta12s
> ever-lasting buttle, you just happened to stay on the way ;-)
LOL, ok I wont ...
Just to clarify, I do like to code correctly ;)
Here's the link, www.kosidesigns.com/quiz
Was just reading up on w3 standards for html, seemed like a good place
to get info ... lol
Thanks for the help VK
-Sarah
VK
Hey, and who's going to update userChoices variable? You need to do it
manually on each choice.
Truthfully I do not understand why you do not want to submit the whole
form in the conventional way over POST - unless there are some extras
I'm not aware of ?
Sta12s
> manually on each choice.
Um ... I took that code out ... I already said I did it through a form
now ...
> Truthfully I do not understand why you do not want to submit the whole
> form in the conventional way over POST - unless there are some extras
> I'm not aware of ?
My problem with the conventional POST is that the form looses all the
values when I hide my DIVs. Which doesn't make any sense;
1. When the value is hidden it does pass to POST, however the last
value to be declared is passed, not the value that is selected
2. When I use radio buttons with a onClick the value gets lost after
the onClick is called - I'm not sure if it is a DIV problem or a Java
problem ...
Anyhoos ... if you're still up to help - many thanks - I'm gonne be
reading to figure this out ...
As always, my code is @ www.kosidesigns.com/quiz and js file is
www.kosidesigns.com/quiz/showHide.js
HAPPY THANKSGIVING!!!!
-Sarah
Sta12s
To answer my first question ... function to POST, it's not required!!
Randy, you were so right when you said I could do it through a FORM ...
duh!!
To answer my second question about onClick
There is a lot of BAD information on the net about onClick - but
basically you can assign anything you want to it (ok, not anything but
you guys can argue over what can and can't ;). In my case I wanted to
assign a variable using onClick, when the simplist answer was to do as
fallows;
<FORM NAME="form" METHOD=POST ACTION="myAction.php">
<INPUT NAME="name" VALUE="value" TYPE=type
ONCLICK="javascript:myFunction()>Blah
<INPUT TYPE=submit VALUE="Click Me!">
</FORM>
insted of my psuedo code which was ...
<a href="javascript:function()
onClick="javascript:assignValue()>Blah</a>
Ok, here is the really funny part ... I forgot a "=" in my code - so my
form works just fine >< ... LOL ... thought you might get a kick out of
that!!
Once again, thanks so much for "pullin my head outta da sand" Jack ;)
Happy Thanksgiving and I promise not to post here again till I read the
CCnR's ;)
*hugs*
Sarah
Richard Cornford
>Richard Cornford wrote:
>> You posted code that demonstrates the use of a formulation that
>> is known to be directly harmful and completely unnecessary.
>> In doing that you are potentially doing harm to others.
>
> Richard,
> Are you going anywhere in the Internet besides clj? People
> just doing what they see on the major web-sites
So what is the rationale here? Are you proposing that it should be
acceptable to give bad advice because it is possible to easily find
examples of people doing worse?
> where <a href="javascript:someFunction()" became a standard
> de-facto (even w/o traditional void() wrapper!).
Making a call to a function that returns undefined (by default or
design) the operand for the void operator is a pointless action. If it
is traditional then that demonstrates that traditions ore often not
informed.
> They see it in Hotmail,CNN, MSN, Yahoo...
The also see it in 'tutorial' web sites, books and in Usenet posts by
people who don't know what they are doing. That many people are not
aware that it causes problems is evident from the number of posts to
this group relating to problems that it has caused. But finding evidence
of people doing something that is a bad idea does not make it a good
idea.
> It is not totally correct, it is not academically approved,
> there are better ways: but rather often people wants and
> chooses what is more convenient and not what is more correct.
One more time, for the extremely slow, the activation of a javascript
pseudo protocol HREF is treated by IE as navigation. Upon navigation
IE switches into a 'waiting state' pending the replacement of the
current page. It says in this state until the current page is replaced
so if the javascript pseudo-protocol HREF does not result in the
replacement of the current page any subsequent script execution will
be interacting with IE in this new (and degraded) state.
Upon entering this state IE stops doing many of the things that it
was previously doing, and it stops providing, or allowing the
scripting of, various facilities that it had previously provided.
Many symptoms of this state change have been the subject of questions
on this group over the years that I have been reading it, the most
visible, and so easily demonstrated, of which are that IE will stop
animating animated GIFs, will stop downloading resources such as
images (so rollovers may stop working) and it stops acting upon META
refresh. Many less easily demonstrated symptoms have been reported
and observed. They take the general form of reports of IE exhibiting
particular behaviour up until the point when a user first clicks a
javascript pseudo-protocol HREF and then behaving differently (usually
less desirably) from then on until the page is re-loaded.
This change in state is a bad thing because it compounds the problem
of diversity in the features and facilities provided by various
browsers by adding two distinct types of scripting environment in
the same browser (and the one that you cannot avoid supporting in
a commercial context); the normal expected behaviour and the
degraded post-navigation request behaviour.
This change in state, and consequent change in the behaviour of IE
can be avoided entirely by not using javascript pseudo-protocol HREFs,
and the use of javascript pseudo-protocol HREFs is entirely
unnecessary when scripting web pages.
This is not a question of academic correctness. There is an argument for
avoiding i8t because of academic correctness, which can be left to the
HTML experts to worry about. Here we are interested in browser scripting
and executing javascript pseudo-protocol HREFs has practical
consequences that are detrimental to the task of scripting web browsers.
The fact that it puts IE into a degraded state is enough to make it a
bad idea, and to make anyone still proposing it after they have been
told why it is a bad idea a fool.
> (think of innerHTML). A bunch of lasy uneducated amateurs,
> I know ;-)
Either that, or just people who trust the people who give then advice,
without the ability to see when that advice is bad.
> But you cannot just keep screaming on anyone that Hotmail,
> MSN or Yahoo have no idea about web-development
Who is screaming? We can see that probably the majority of web
developers working on major public web sites have little idea of what
they are doing. It is only necessary to enable pop-up errors in IE to
see evidence of scripts failing left right and centre.
> and only few "selected" people in clj have it.
The regular contributors to clj are not the only web developers who have
an interest in understanding the technologies they use.
> Most of the time you'll get just a homorious effect.
> Keep suggecting, but do not go ballistic over it.
> Or even better - let's make a JavaScript-...
Let's?
> as I suggested ...
<snip>
There is little point in you suggesting anything as you have too often
demonstrated that you are a fool to be taken seriously.
Richard.
Randy Webb
Please quote what you are replying to.
If you want to post a followup via groups.google.com, don't use the
"Reply" link at the bottom of the article. Click on "show options" at
the top of the article, then click on the "Reply" at the bottom of the
article headers.
> Ok ... I figured it out
Glad you did.
> To answer my first question ... function to POST, it's not required!!
> Randy, you were so right when you said I could do it through a FORM ...
> duh!!
Thats "Randy Jack Ass" to you :)
> To answer my second question about onClick
>
> There is a lot of BAD information on the net about onClick - but
> basically you can assign anything you want to it (ok, not anything but
> you guys can argue over what can and can't ;). In my case I wanted to
> assign a variable using onClick, when the simplist answer was to do as
> fallows;
There is a lot of BAD information on the net about a lot of things,
including onclick.
> <FORM NAME="form" METHOD=POST ACTION="myAction.php">
> <INPUT NAME="name" VALUE="value" TYPE=type
> ONCLICK="javascript:myFunction()>Blah
onclick="myFunction()"
Unless you are dealing with dual scripting with VBScript, the
javascript: label is not needed.
> <INPUT TYPE=submit VALUE="Click Me!">
> </FORM>
>
> insted of my psuedo code which was ...
>
> <a href="javascript:function()
> onClick="javascript:assignValue()>Blah</a>
>
> Ok, here is the really funny part ... I forgot a "=" in my code - so my
> form works just fine >< ... LOL ... thought you might get a kick out of
> that!!
>
> Once again, thanks so much for "pullin my head outta da sand" Jack ;)
Sure thing.....