Count check boxes

[S.T.]

It's useful to try and work without frameworks as much as possible
until you've really honed your JS skills and knowledge. But there
comes a point where you're just being obstinate and completely missing
the point of actually using a framework. I'm saying this to you
because I was in the exact same mental boat as you clearly are now
until recently when I signed on with an all JQ shop where they'd
really rather you didn't DOM script 800 lines when you could do it in
a handful of JQ statements which do not obscure what's actually going
on if you know both JS and JQ.

On the flipside of that coin, JQ is not a workaround for actually
learning JavaScript. If you don't know what's really going on behind
the scenes you can very easily write painfully slow code. It's a lot
like regular expressions. It's powerful enough that if you don't know
what you're doing you can cripple your performance with a single line.

That's a fair critique. I certainly use JQuery as a crutch. All things
being equal, I'd like to know all aspects of Javascript (ECMAscript...
whatever the purists want to call it these days) inside and out.

That said, all things aren't equal. Time spent learning the most
intimate details of Javascript is time taken away from generating
revenue or gaining knowledge of other technologies. And thankfully,
JQuery takes some of the more complicated and used JS concepts (DOM
selection and manipulation and Ajax/XHR) and substantially rounds out
the learning curve. Despite the doomsday predictions seen on this board,
the 'cons' of using JQuery have been trivial at best.

The opening of the DOM manipulation and Ajax to 'the masses' does, of
course, open the risk of poorly thought out coding.

Bloat is a risk for the true novices as well, particularly if they
simply add a slew of plugins (or worse, a complete JQueryUI script) to
accommodate relatively simple functionality. In this newsgroup however,
the 'bloat' argument seems to be in the context of the library itself.
I'd argue if you have a DOM so complicated so as to actually cause
JQuery to have perceivable performance issues, you'd be far better off
learning how to design a UI and/or page layout before bothering to learn
every facet of Javascript.

And for Garrett,
// checked checkboxes beginning with 'booking['
var i = $("input[name^='booking[']:checked","#myform").length;
// total checkboxes beginning with 'booking['
var j = $("input[name^='booking[']","#myform").length;

... where 'myform' is the ID of the form

 

[Garrett Smith]

Daniel wrote:
Hello,
I have a page which has a set of checkboxes and would like some
guidance o how I can get an accurate count of the total number of
boxes and the number of checked. Their synthax is
<input type="checkbox" name="booking[0]" value="1" />
<input type="checkbox" name="booking[1]" value="1" />
<input type="checkbox" name="booking[2]" value="1" />
With JQuery, it's...
var i = $("input[name^='booking[']:checked").length;

Whatever that one line does, it is neither more efficient nor less error
than the reliable and standard approach posted.

That line of code almost attempst to answer the question. It might tell
how many are checked, so that would seem to address the "number of
checked" part of the question.

The first half of OP question:-
| guidance o how I can get an accurate count of the total number of
| boxes

Not that that isn't possible, but what is the reason for using such
inefficinet code when:

document.forms.myform.elements.booking

- is very clear.

The standard approach doesn't obscure what is going on and doesn't add
an extra jQuery.js and doesn't add the overhead of function calls.

... plus, of course, the library which the user probably has cached
already from the Google CDN.
And you have to put up with half this newsgroup rambling about the pure
evil that is JQuery.

You don't have to put up with anything. Stop the martyrdom and show us a
test of how much more efficient "the magic of jquery" is and why it is
more reliable.

Grow a pair and get a real name.

Garrett

It's useful to try and work without frameworks as much as possible
until you've really honed your JS skills and knowledge.

So you've mastered it all, and now you can use jQuery. How about that.

But there

comes a point where you're just being obstinate and completely missing
the point of actually using a framework. I'm saying this to you
because I was in the exact same mental boat as you clearly are now
until recently when I signed on with an all JQ shop where they'd
really rather you didn't DOM script 800 lines when you could do it in

I'll stick with rational problem solving over religion.

Garrett

 

[Garrett Smith]

Pherdnut wrote:
[...]

On the flipside of that coin, JQ is not a workaround for actually
learning JavaScript. If you don't know what's really going on behind
the scenes you can very easily write painfully slow code. It's a lot
like regular expressions. It's powerful enough that if you don't know
what you're doing you can cripple your performance with a single line.

That's a fair critique. I certainly use JQuery as a crutch. All things
being equal, I'd like to know all aspects of Javascript (ECMAscript...
whatever the purists want to call it these days) inside and out.

Whatever it is that you do, don't you think it makes sense to learn what
it is called, at the very least? It would be akin to a paremedic saying:-

"I help out those people that get hurt (paramedics, or whatever the
purists call it)".

That said, all things aren't equal. Time spent learning the most
intimate details of Javascript is time taken away from generating
revenue or gaining knowledge of other technologies. And thankfully,
JQuery takes some of the more complicated and used JS concepts (DOM
selection and manipulation and Ajax/XHR) and substantially rounds out
the learning curve. Despite the doomsday predictions seen on this board,
the 'cons' of using JQuery have been trivial at best.

The opening of the DOM manipulation and Ajax to 'the masses' does, of
course, open the risk of poorly thought out coding.

Bloat is a risk for the true novices as well,

jQuery *is* bloat.

particularly if they

simply add a slew of plugins (or worse, a complete JQueryUI script) to
accommodate relatively simple functionality. In this newsgroup however,
the 'bloat' argument seems to be in the context of the library itself.
I'd argue if you have a DOM so complicated so as to actually cause
JQuery to have perceivable performance issues,

Like github or reddit?

you'd be far better off

learning how to design a UI and/or page layout before bothering to learn
every facet of Javascript.

And for Garrett,
// checked checkboxes beginning with 'booking['
var i = $("input[name^='booking[']:checked","#myform").length;
// total checkboxes beginning with 'booking['
var j = $("input[name^='booking[']","#myform").length;

.. where 'myform' is the ID of the form

Compare to what I posted:-

<script type="text/javascript">
function showChecked(){
var bbs = document.forms[0].elements.booking,
bookingCount = bbs.length, i, r = [];
for(i = 0; i < bookingCount; i++) {
if(bbs.checked) {
r.push(bbs.value);
}
}
document.getElementById("m").firstChild.data = ("checked:" +
r.join(", "));
return false;
}
</script>

Using jQuery saves a few LOC but introduces inherent complexity and
overhead. Making two queries of the query selector relies on code that
does considerably more than the performing the standard approach.

The way that it is written using DOM standard code is simple.
Abstractions aren't really justified on the basis of simplifying --
they'll only make things more complicated here, and so by using a
standard approach, 0 additional overhead is introduced for said absent
abstractions.

Garrett

 

[S.T.]

Whatever it is that you do, don't you think it makes sense to learn what
it is called, at the very least?

Really, I don't care.

Like github or reddit?

Github runs a 1700 line (LONG lines), 134K when uncompressed 'default'
script on every single page.

I'm not sure you can blame JQuery for a site that decides to take the
combined JS functionality of every page of it site and include it on
EVERY single page of it's site. It's simply an absurd, or lazy, approach.

I don't care if that functionality was 'pure' javascript... add that
much clutter, DOM calls, and so forth to every page and you're going to
bog down some systems. MAYBE, just MAYBE, you could do a default 300KB
script using 'native' JS that included all the site's functionality in
one script and have it run fine -- and it is, in fact, JQuery causing
the issue here -- but it would be a stupid approach regardless.

Don't know who's complaining about Reddit. Looks like they're doing
some JSON calls -- perhaps the replying server was slow? Dunno. Never
had a problem on that site or known anyone to complain. I have noted
some slowing issues with Github before though.

And for Garrett,
// checked checkboxes beginning with 'booking['
var i = $("input[name^='booking[']:checked","#myform").length;
// total checkboxes beginning with 'booking['
var j = $("input[name^='booking[']","#myform").length;

.. where 'myform' is the ID of the form

Compare to what I posted:-

<script type="text/javascript">
function showChecked(){
var bbs = document.forms[0].elements.booking,
bookingCount = bbs.length, i, r = [];
for(i = 0; i < bookingCount; i++) {
if(bbs.checked) {
r.push(bbs.value);
}
}
document.getElementById("m").firstChild.data = ("checked:" + r.join(",
"));
return false;
}
</script>

Using jQuery saves a few LOC but introduces inherent complexity and
overhead. Making two queries of the query selector relies on code that
does considerably more than the performing the standard approach.

You don't see the difference between your code and:

var i = $("input[name^='booking[']:checked","#myform").length;
var j = $("input[name^='booking[']","#myform").length;

Really?

It's not a few LOC, it's quite a bit less actually.

It's also remarkably easier to look back at and see exactly what it's
doing with a quick scan. I wouldn't bother commenting any of this, even
in the middle of a much longer script. Any developer with a basic
knowledge of JQuery could see exactly what those lines are doing in an
instant (though I'd probably use better-named variables to help).

Using your code, I'd HIGHLY recommend you add some commenting in case
other developers may need to come back and revisit the code. It's not
obvious what it's doing at a quick glance, especially in the middle of a
script when surrounded by 4x the lines of 'native' JS code versus what a
largely JQuery-based script would have.

In the event the script didn't give me the results I expected (a syntax
error or something), "my" code is FAR easier to debug. About 50 fewer
places to look for a missed bracket, a comma instead of a period,
'firstchild' instead of 'firstChild', etc.

The way that it is written using DOM standard code is simple.
Abstractions aren't really justified on the basis of simplifying --
they'll only make things more complicated here, and so by using a
standard approach, 0 additional overhead is introduced for said absent
abstractions.

I get that JQ adds some overhead. Really, I do. But, to date, the
effects of this extra overhead that I've noted have been trivial at
worst, non-existent in all likelihood. And if you're suggesting that I
should avoid any additional overhead at all simply for the sake of
avoiding any additional overhead, and the consequences are every time I
need to do something basic like count checked boxes I need to whip up...

function showChecked(){
var bbs = document.forms[0].elements.booking,
bookingCount = bbs.length, i, r = [];
for(i = 0; i < bookingCount; i++) {
if(bbs.checked) {
r.push(bbs.value);
}
}
document.getElementById("m").firstChild.data = ("checked:" +
r.join(", "));
return false;
}

.... well, that's a deal breaker. I'd need to actually see some evidence
what *I* was doing with JQuery (not Github's approach) was causing
user-perceivable slowdowns on my sites before I'd commit to wasting that
much time and effort to redo what's already been done for me.

There's lots of warnings in this group about the risks and inherit flaws
of using libraries, but a conspicuous absence of real world examples.

 

[Garrett Smith]

Really, I don't care.


Github runs a 1700 line (LONG lines), 134K when uncompressed 'default'
script on every single page.

Which? bundle.js? That file is cacheable. Regardless, downloading that
file does not cause a slow script dialog box. That is caused by a script
that executes slowly.

I'm not sure you can blame JQuery for a site that decides to take the
combined JS functionality of every page of it site and include it on
EVERY single page of it's site. It's simply an absurd, or lazy, approach.

Possibly. There is also the possibility that most of that functionality
is used in a single session. That would make caching attractive and
could actually make sense. I can't really say why they've chosen that
approach.

I don't care if that functionality was 'pure' javascript... add that

what is 'pure' javascript?

much clutter, DOM calls, and so forth to every page and you're going to
bog down some systems. MAYBE, just MAYBE, you could do a default 300KB
script using 'native' JS that included all the site's functionality in
one script and have it run fine -- and it is, in fact, JQuery causing
the issue here -- but it would be a stupid approach regardless.

I don't understand what that means.

Don't know who's complaining about Reddit.

Came up just within this last week.

Message-ID: <[email protected]>

Looks like they're doing

some JSON calls -- perhaps the replying server was slow? Dunno. Never
had a problem on that site or known anyone to complain. I have noted
some slowing issues with Github before though.

And for Garrett,
// checked checkboxes beginning with 'booking['
var i = $("input[name^='booking[']:checked","#myform").length;
// total checkboxes beginning with 'booking['
var j = $("input[name^='booking[']","#myform").length;

.. where 'myform' is the ID of the form

Compare to what I posted:-

<script type="text/javascript">
function showChecked(){
var bbs = document.forms[0].elements.booking,
bookingCount = bbs.length, i, r = [];
for(i = 0; i < bookingCount; i++) {
if(bbs.checked) {
r.push(bbs.value);
}
}
document.getElementById("m").firstChild.data = ("checked:" +
r.join(", "));
return false;
}
</script>

Using jQuery saves a few LOC but introduces inherent complexity and
overhead. Making two queries of the query selector relies on code that
does considerably more than the performing the standard approach.

You don't see the difference between your code and:

var i = $("input[name^='booking[']:checked","#myform").length;
var j = $("input[name^='booking[']","#myform").length;

Really?

It's not a few LOC, it's quite a bit less actually.

Identifier - i - tells how many "booking" checkboxes are checked, not which.

It's also remarkably easier to look back at and see exactly what it's
doing with a quick scan.

It also covers up a the fact that the approach should have used standard
HTML from the start, not including square brackets in the name.

I wouldn't bother commenting any of this, even

in the middle of a much longer script. Any developer with a basic
knowledge of JQuery could see exactly what those lines are doing in an
instant (though I'd probably use better-named variables to help).

Using your code, I'd HIGHLY recommend you add some commenting in case

THe method body is 8 lines and the name is - showChecked - is clear.
That could be renamed to a method that getst the checked checkboxes. A
comment would add clutter.

Finding checkboxes is easy and simple.

other developers may need to come back and revisit the code. It's not
obvious what it's doing at a quick glance, especially in the middle of a
script when surrounded by 4x the lines of 'native' JS code versus what a
largely JQuery-based script would have.

In the event the script didn't give me the results I expected (a syntax
error or something), "my" code is FAR easier to debug.

No, because it uses abstractions where none are needed.


About 50 fewer

places to look for a missed bracket, a comma instead of a period,
'firstchild' instead of 'firstChild', etc.


I get that JQ adds some overhead. Really, I do. But, to date, the
effects of this extra overhead that I've noted have been trivial at
worst,

non-existent in all likelihood. And if you're suggesting that I

should avoid any additional overhead at all simply for the sake of
avoiding any additional overhead, and the consequences are every time I
need to do something basic like count checked boxes I need to whip up...

No, finding checkboxes is easy. Adding an abstraction just makes
debugging harder.

The further away from the problem the error, the harder it will be to
find. Finding an error in the - for - loop is easy. Much easier than
finding an error in the bowels of jQuery code.

You seem to think that the code I've written is error prone, and that it
would be easy to misplace a bracket or mispell dom properties or methods.

Understanding the syntax of the language is important. For someone who
says they don't care to know what the name of the language is, it's
going to be hard to get that person to learn the syntax, and you did say
that you do do not want to learn what language is called: "Really, I
don't care" (sic).

A professional can be expected to know the names of standard dom
properties and their compatibility with at least common web browsers.

function showChecked(){
var bbs = document.forms[0].elements.booking,
bookingCount = bbs.length, i, r = [];
for(i = 0; i < bookingCount; i++) {
if(bbs.checked) {
r.push(bbs.value);
}
}
document.getElementById("m").firstChild.data = ("checked:" + r.join(",
"));
return false;
}

... well, that's a deal breaker. I'd need to actually see some evidence
what *I* was doing with JQuery (not Github's approach) was causing
user-perceivable slowdowns on my sites before I'd commit to wasting that
much time and effort to redo what's already been done for me.

JQuery was published before the author had even basic understanding of
the language or the DOM and gained widespread acceptance by the less
knowledgeable masses.

jQuery is advertised as magic to those who are too lazy to learn the
language (really, you don't care) and the DOM. It is marketed as "magic"
and used as a crutch (you said it).

Generally those who don't want to learn or try hard are going to look
for an easy solution.

jQuery is not a viable tool for professional development.

There's lots of warnings in this group about the risks and inherit flaws
of using libraries, but a conspicuous absence of real world examples.

Apparently you missed the part of "Errors in IE6". There are plenty of
examples in the archives, even more on the jquery users list.

Jquery implementation code usually has chained methods and long,
anonymous function expressions. That sort of code can be harder to
understand and maintain. A good example of that is on a recent Firebug
groups discussion.

http://groups.google.com/group/firebug/browse_thread/thread/cfde50f8184a67c9

The type of code leads to things that are 99% of the way there,
unmaintainable, and not forwards compatible.

Please see the FAQ, linked below, which has several resources to learn
from.

Garrett

 

[Richard Cornford]

Garrett Smith wrote:
[...]> It also covers up a the fact that the approach should have used

standard HTML from the start, not including square brackets in the
name.

                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
What are you getting at? That '[]' shouldn't be used in names
according to something like a personal style guide, or that it
mustn't be used in order to have valid HTML?

Square bracket characters are perfectly valid in the NAME (but not ID)
attributes of HTML form control elements. However, their use in that
context does appear to be a running source of issues/problems when
(more or less, inexperienced) people then attempt to interact with
such named form control elements. Sufficiently so that this group's
FAQ has had an entry on the subject for many years now.

Richard.