Fucntion to POST???

V

VK

Sta12s said:

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 ?
 
S

Sta12s

Hey, and who's going to update userChoices variable? You need to do it
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
 
S

Sta12s

Ok ... I figured it out

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
 
R

Richard Cornford

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.
 
R

Randy Webb

Sta12s said the following on 11/24/2005 4:09 PM:

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.....
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,734
Messages
2,569,441
Members
44,832
Latest member
GlennSmall

Latest Threads

Top