$('input[name="' + obj.name + '"]').attr('checked', false);
On Jan 8, 8:45 am, Henry <rcornf...@raindrop.co.uk> wrote:
> jq noob wrote:
> > Sorry this might be really simple but there is a reason my
> > nickname is jq noob! I was wondering how to convert this JS
> > function into proper Jquery code.
>
> "Correct" and "proper" are going to be very much influenced by various
> people's opinions. You have not explained what - obj - is expected to
> be in your function. It looks like it could be an <INPUT type="radio">
> element, but it could also be any JS object that happens to have a -
> name - property that corresponds with the name of a set of <INPUT
> type="radio"> elements in a form with the name (or possibly ID)
> "editResource". This leads to some guessing, but my guess is that the
> question you want the answer to is; given a reference to an <INPUT
> type="radio"> element, how to use JQuery to assign a - false - value
> to the - checked - property of all of the like-named "radio" elements
> in a form named "editResource" (though if you started with an <INPUT
> type="radio"> element from inside the form then you can get a
> reference to the containing form from the element's - form - property
> and so could use that as a context and so not need to know the name of
> the form).
>
> Disregarding the JQuery aspect of this, there are two important
> javascript issues that you would benefit form learning about.
>
> > function uncheckRadio(obj) {
> > var choice = eval("document.editResource." + obj.name);
>
> Historically the - eval - function has been misused, and here you seem
> to have an example of its most common (and unnecessary) abuse; the
> runtime construction of string representations of dot notation
> property accessors and then - eval -ing them in order to resolving the
> property accessor. In addition to "dot notation" property accessors,
> javascript has "bracket notation" property accessors, and bracket
> notation property accessors do a runtime evaluation of an expression
> and a type-conversation to a string, and then use that string as the
> name of the property to be looked up. See:-
>
> <URL:http://www.jibbering.com/faq/faq_notes/square_brackets.html>
>
> Thus:-
>
> var choice = eval("document.editResource." + obj.name);
>
> - can be replaced with:-
>
> var choice = document.editResource[ obj.name ];
>
> - and achieve the same outcome, but faster (about 7 to 80 times
> faster, depending on the browser/js-engine).
>
> (If - obj - does happen to be a reference to an <INPUT type="radio">
> element in the ' editResource' form then the above property accessor
> could also be re-written as:-
>
> var choice = obj.form[ obj.name ];
>
> - allowing the FORM to be handled anonymously.)
>
> > for (i = 0; i < choice.length; i++)
>
> There is a general programming axiom that no variable should ever be
> given more scope than it absolutely needs. Above you have - i = 0 -,
> and that is an assignment to a property of the global object with the
> name "i", which to all practical purposes is an assignment to a global
> variable. But the - i - variable is a loop counter and loop counters
> generally don't need to be in scope outside of the loop that uses
> them. However, javascript's smallest scoping unit is the function. It
> is never possible for a variable to be less visible than being visible
> to the entire body of a function, but that still means that a loop
> counter variable that does not need to be visible outside of its loop
> should not have a scope that extends beyond the body of the function
> in which the loop appears (it should not have more scope, but cannot
> have less).
>
> Thus - i - should be declared with the - var - keyword inside the
> function. Making it a local variable (local to the function) rather
> than its ending up as what is effectively a global variable.
>
> In the function above that change would have no impact on how anything
> worked (except the resolution of a local variable should be, very
> fractionally, faster than the resolution of a global variable), but
> the consequences of allowing variables more scope than they need might
> be illustrated by considering what happens if, in the body of the loop
> above, another function was called and that function also contained a
> loop using an undeclared (so also global) - i - variable as its
> counter (and habitually using the same identifiers for loop counters
> is completely normal and common). When the contained function is
> called its loop updates the global - i - variable, and when the
> function returns and the fist loop iterates it looks at the, now
> modified, global - i - and probably does the wrong thing (prematurely
> terminates, or loops for eve, or some such).
>
> > {
> > choice[i].checked = false;
> > }
> > }
