[drupal-devel] [feature] Check All | None on Content List Page (admin/node)

Mon Jul 25 15:14:10 UTC 2005

Issue status update for 
http://drupal.org/node/20641
Post a follow up: 
http://drupal.org/project/comments/add/20641

 Project:      Drupal
 Version:      cvs
 Component:    node.module
 Category:     feature requests
 Priority:     normal
 Assigned to:  Anonymous
 Reported by:  jjeff
 Updated by:   Steven
 Status:       patch

+1 for concept, -5 on implementation:

* It does not degrade. Preferably these extra controls would be added
onload through JS. At worst, we generate them with an inline <script>
tag which calls an API.
* The code belongs in a .js file with a killswitch, like the other JS
in Drupal.
* DOM methods are preferred to legacy accessors like document.forms
IMO. We should use getElementsByTagName() instead.
* Instead of a link, why not use a checkbox in the header row? Check it
to select all, uncheck it to select nothing. It is ugly to use a
separate table row for each of them this.
* We should be more selective with this. We should restrict the list of
boxes to check by id/name.

Steven

Previous comments:
------------------------------------------------------------------------

Sat, 16 Apr 2005 17:53:51 +0000 : jjeff

Attachment: http://drupal.org/files/issues/node_module_check_all.patch (1.23 KB)

>From the "what a great time-saver" department:

Here is a short patch to node.module that adds a "Check all | none"
javascript link to the bottom of the content listing table on
admin/node. By clicking "all" or "none" you can select or deselect all
of the check boxes in the table at once.

The javascript is very non-invasive, should work older (non-DOM)
browsers, and non-javascript browsers will simply lose this function.

The patch also adds the attribute [name = "node-admin"] to the [form]
tag. I don't know if there is a form naming convention, but this was
the best guess I could come up with by looking at the page source. And
incidentally, if Drupal is going to move toward javascript/ajax
functioning, all forms are going to need 'name' and 'id' tags. Most
don't have these now.

-Jeff

------------------------------------------------------------------------

Thu, 21 Apr 2005 18:49:30 +0000 : Bèr Kessels

-1. Its up to the client to provide such interface tricks. Most clients
can do this with bookmarklets already.

------------------------------------------------------------------------

Fri, 22 Apr 2005 12:02:14 +0000 : Junyor

How would you propose that a client implement this?  As of now, there's
no common attribute that the client could use to determine that the
checkboxes are related.  Theoretically, it could be done if the
checkboxes shared a common name.  But what would the UI look like?

My point is, no UA has implemented this and there's a working solution
used throughout the Web.  Let's use that solution.

------------------------------------------------------------------------

Fri, 22 Apr 2005 13:00:20 +0000 : Bèr Kessels

http://www.squarefree.com/bookmarklets/forms.html is the one you are
looking for. See "Toggle checkboxes".

------------------------------------------------------------------------

Fri, 22 Apr 2005 13:05:55 +0000 : Junyor

Checking all checkboxes on a page is not a viable solution for most
cases (though it may work here).

------------------------------------------------------------------------

Fri, 22 Apr 2005 13:29:14 +0000 : moshe weitzman

It is silly to require users to install bookmarklets from 3rd party web
sites in order to easily use our pages. Every web mail application I've
used provides a 'check all' feature. This is not a "client hack". It is
ECMAscript, which is a web standard.  +1

------------------------------------------------------------------------

Fri, 22 Apr 2005 16:40:40 +0000 : factoryjoe

Bookmarklets are not a viable solution when viewing a site on
kiosk/school web browser. +1 for this functionality, but I really think
that these scripts belong in a drupal utility.js file, similar to Rails'
prototype.js [1] file.

It also seems to me that there needs to be a bit more logic about where
this kind of "check all" | "deselect all" link shows up. As it is, I
couldn't tell if it gets added to the table header, footer, or shows up
after... I think tossing it in the admin UI makes good sense for now,
but I imagine that this would also be useful in more user-facing UIs.
[1]
http://dev.rubyonrails.com/file/trunk/actionpack/lib/action_view/helpers/javascripts/prototype.js

------------------------------------------------------------------------

Fri, 22 Apr 2005 22:56:58 +0000 : jjeff

Yes, downloading a bookmarklet is rediculous. It might be a solution for
the people who are reading this, but aren't we trying to appeal to a
larger audience than the development community?

This script only (un)checks the boxes within the given form. The
bookmarklet hits the whole page.

I understand that it's both narrow thinking and bad web design to
require JavaScript of the client browser. But let's be honest, it's
2005 and most browsers have it. Even Opera on my cell phone has some
basic JavaScript capability. As in this case, the JavaScript should not
define an essential function, nor "get in the way" for non-javascript
browsers. Certainly, JavaScript can be abused, but simply using it does
not amount to inaccessiblity nor standards non-comliance.

And there are honestly some AMAZING things being done with AJAX and
lesser JavaScript. Anyone who has used Flickr can attest to this. Their
system uses both AJAX-style javascript and Flash in a way that provides
quick and efficient content editing and photo presentation, but
degrades gracefully.

Perhaps there should be a larger discussion about a JavaScript layer or
some sort of standard for Drupal. 'Cause let's be honest, a little DHTML
in the menu navigation would save a lot of time -- click 'administer',
wait for page to load, click 'settings', wait for the page to load,
click the thing you want -- it's just not efficient (and I know I can
fold 'em out using admin/menu, but that kinda kills the advantage of
having a heirarchy). The Rail prototype library is certainly
intreguing. Perhaps Drupal could adopt something like this, or build
something of our own.

Mathias, RichardB, and I have been doing some really cool stuff with
the TinyMCE JavaScript WYSIWYG editor. It provides Word-like extended
textarea editing capabilties to users who have the capability, with no
impact on non-capable browsers.

I made this patch as a quick way to get some basic "CMS 101"
functionality on the content list page. But I agree that it would be a
bit of an anomaly to commit this patch without looking at how
JavaScript can benefit the Drupal user interface as a whole.

-Jeff

------------------------------------------------------------------------

Sun, 24 Apr 2005 20:00:12 +0000 : nysus

+1 to the concept.  It should be in core.

I can't comment on the code since I haven't looked at it.

------------------------------------------------------------------------

Fri, 15 Jul 2005 12:46:20 +0000 : com2

Attachment: http://drupal.org/files/issues/node_module_check_all_0.patch (1.11 KB)

The same patch now both in header and footer of the table & I adapted it
to cvs.

------------------------------------------------------------------------

Tue, 19 Jul 2005 03:54:52 +0000 : moshe weitzman

this satisfies a great nead, but i'd rather see a more generic version
of check(what) in drupal.js. the one here is defined within BODY tag
which isn't so clean