[drupal-devel] [feature] Check All | None on Content List Page (admin/node)
Issue status update for http://drupal.org/node/20641 Project: Drupal Version: cvs Component: node.module Category: feature requests Priority: normal Assigned to: Anonymous Reported by: jjeff Updated by: jjeff Status: patch 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 jjeff
Issue status update for http://drupal.org/node/20641 Project: Drupal Version: cvs Component: node.module Category: feature requests Priority: normal Assigned to: Anonymous Reported by: jjeff Updated by: Bèr Kessels Status: patch -1. Its up to the client to provide such interface tricks. Most clients can do this with bookmarklets already. Bèr Kessels Previous comments: ------------------------------------------------------------------------ April 16, 2005 - 18:53 : 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
Issue status update for http://drupal.org/node/20641 Project: Drupal Version: cvs Component: node.module Category: feature requests Priority: normal Assigned to: Anonymous Reported by: jjeff Updated by: Junyor Status: patch 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. Junyor Previous comments: ------------------------------------------------------------------------ April 16, 2005 - 18:53 : 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 ------------------------------------------------------------------------ April 21, 2005 - 19:49 : Bèr Kessels -1. Its up to the client to provide such interface tricks. Most clients can do this with bookmarklets already.
Issue status update for http://drupal.org/node/20641 Project: Drupal Version: cvs Component: node.module Category: feature requests Priority: normal Assigned to: Anonymous Reported by: jjeff Updated by: Bèr Kessels Status: patch http://www.squarefree.com/bookmarklets/forms.html is the one you are looking for. See "Toggle checkboxes". Bèr Kessels Previous comments: ------------------------------------------------------------------------ April 16, 2005 - 18:53 : 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 ------------------------------------------------------------------------ April 21, 2005 - 19:49 : Bèr Kessels -1. Its up to the client to provide such interface tricks. Most clients can do this with bookmarklets already. ------------------------------------------------------------------------ April 22, 2005 - 13:02 : 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.
Issue status update for http://drupal.org/node/20641 Project: Drupal Version: cvs Component: node.module Category: feature requests Priority: normal Assigned to: Anonymous Reported by: jjeff Updated by: Junyor Status: patch Checking all checkboxes on a page is not a viable solution for most cases (though it may work here). Junyor Previous comments: ------------------------------------------------------------------------ April 16, 2005 - 18:53 : 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 ------------------------------------------------------------------------ April 21, 2005 - 19:49 : Bèr Kessels -1. Its up to the client to provide such interface tricks. Most clients can do this with bookmarklets already. ------------------------------------------------------------------------ April 22, 2005 - 13:02 : 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. ------------------------------------------------------------------------ April 22, 2005 - 14:00 : Bèr Kessels http://www.squarefree.com/bookmarklets/forms.html is the one you are looking for. See "Toggle checkboxes".
Issue status update for http://drupal.org/node/20641 Project: Drupal Version: cvs Component: node.module Category: feature requests Priority: normal Assigned to: Anonymous Reported by: jjeff Updated by: moshe weitzman Status: patch 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 moshe weitzman Previous comments: ------------------------------------------------------------------------ April 16, 2005 - 12:53 : 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 ------------------------------------------------------------------------ April 21, 2005 - 13:49 : Bèr Kessels -1. Its up to the client to provide such interface tricks. Most clients can do this with bookmarklets already. ------------------------------------------------------------------------ April 22, 2005 - 07:02 : 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. ------------------------------------------------------------------------ April 22, 2005 - 08:00 : Bèr Kessels http://www.squarefree.com/bookmarklets/forms.html is the one you are looking for. See "Toggle checkboxes". ------------------------------------------------------------------------ April 22, 2005 - 08:05 : Junyor Checking all checkboxes on a page is not a viable solution for most cases (though it may work here).
Issue status update for http://drupal.org/node/20641 Project: Drupal Version: cvs Component: node.module Category: feature requests Priority: normal Assigned to: Anonymous Reported by: jjeff Updated by: factoryjoe Status: patch 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/jav... factoryjoe Previous comments: ------------------------------------------------------------------------ April 16, 2005 - 17:53 : 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 ------------------------------------------------------------------------ April 21, 2005 - 18:49 : Bèr Kessels -1. Its up to the client to provide such interface tricks. Most clients can do this with bookmarklets already. ------------------------------------------------------------------------ April 22, 2005 - 12:02 : 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. ------------------------------------------------------------------------ April 22, 2005 - 13:00 : Bèr Kessels http://www.squarefree.com/bookmarklets/forms.html is the one you are looking for. See "Toggle checkboxes". ------------------------------------------------------------------------ April 22, 2005 - 13:05 : Junyor Checking all checkboxes on a page is not a viable solution for most cases (though it may work here). ------------------------------------------------------------------------ April 22, 2005 - 13:29 : 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
Issue status update for http://drupal.org/node/20641 Project: Drupal Version: cvs Component: node.module Category: feature requests Priority: normal Assigned to: Anonymous Reported by: jjeff Updated by: jjeff Status: patch 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 jjeff Previous comments: ------------------------------------------------------------------------ April 16, 2005 - 12:53 : 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 ------------------------------------------------------------------------ April 21, 2005 - 13:49 : Bèr Kessels -1. Its up to the client to provide such interface tricks. Most clients can do this with bookmarklets already. ------------------------------------------------------------------------ April 22, 2005 - 07:02 : 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. ------------------------------------------------------------------------ April 22, 2005 - 08:00 : Bèr Kessels http://www.squarefree.com/bookmarklets/forms.html is the one you are looking for. See "Toggle checkboxes". ------------------------------------------------------------------------ April 22, 2005 - 08:05 : Junyor Checking all checkboxes on a page is not a viable solution for most cases (though it may work here). ------------------------------------------------------------------------ April 22, 2005 - 08:29 : 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 ------------------------------------------------------------------------ April 22, 2005 - 11:40 : 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/jav...
Issue status update for http://drupal.org/node/20641 Project: Drupal Version: cvs Component: node.module Category: feature requests Priority: normal Assigned to: Anonymous Reported by: jjeff Updated by: nysus Status: patch +1 to the concept. It should be in core. I can't comment on the code since I haven't looked at it. nysus Previous comments: ------------------------------------------------------------------------ April 16, 2005 - 13:53 : 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 ------------------------------------------------------------------------ April 21, 2005 - 14:49 : Bèr Kessels -1. Its up to the client to provide such interface tricks. Most clients can do this with bookmarklets already. ------------------------------------------------------------------------ April 22, 2005 - 08:02 : 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. ------------------------------------------------------------------------ April 22, 2005 - 09:00 : Bèr Kessels http://www.squarefree.com/bookmarklets/forms.html is the one you are looking for. See "Toggle checkboxes". ------------------------------------------------------------------------ April 22, 2005 - 09:05 : Junyor Checking all checkboxes on a page is not a viable solution for most cases (though it may work here). ------------------------------------------------------------------------ April 22, 2005 - 09:29 : 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 ------------------------------------------------------------------------ April 22, 2005 - 12:40 : 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/jav... ------------------------------------------------------------------------ April 22, 2005 - 18:56 : 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
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: com2 Status: patch 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. com2 Previous comments: ------------------------------------------------------------------------ April 16, 2005 - 18:53 : 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 ------------------------------------------------------------------------ April 21, 2005 - 19:49 : Bèr Kessels -1. Its up to the client to provide such interface tricks. Most clients can do this with bookmarklets already. ------------------------------------------------------------------------ April 22, 2005 - 13:02 : 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. ------------------------------------------------------------------------ April 22, 2005 - 14:00 : Bèr Kessels http://www.squarefree.com/bookmarklets/forms.html is the one you are looking for. See "Toggle checkboxes". ------------------------------------------------------------------------ April 22, 2005 - 14:05 : Junyor Checking all checkboxes on a page is not a viable solution for most cases (though it may work here). ------------------------------------------------------------------------ April 22, 2005 - 14:29 : 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 ------------------------------------------------------------------------ April 22, 2005 - 17:40 : 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/jav... ------------------------------------------------------------------------ April 22, 2005 - 23:56 : 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 ------------------------------------------------------------------------ April 24, 2005 - 21:00 : nysus +1 to the concept. It should be in core. I can't comment on the code since I haven't looked at it.
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: moshe weitzman Status: patch 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 moshe weitzman 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/jav... ------------------------------------------------------------------------ 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.
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/jav... ------------------------------------------------------------------------ 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
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: jjeff Status: patch I pretty much agree with Steven. I like the idea of a 'master' checkbox in the header and the code should be sure to degrade. And I agree with Moshe that there should be some functions for this type of thing in drupal.js. I'm going to go one further and suggest a form_mastercheckbox() function. By default it would check all checkboxes within the current form. But are there consistent patterns to how similar checkboxes are named? I could set it up so that you could pass a regex and javascript would compare names (or ids) against it, but it seems like there should be a more efficient way of handling that. It looks like the form_checkboxes() outputs a series of checkboxes with the naming scheme: name="edit[checkboxname][]" and no id These would be easy enough to target, but the more common use of form_mastercheckbox() would probably be (as we've been talking about in this thread), all checkboxes in an html table column. And these are called using form_checkbox(). These have the format: name="edit[checkboxname]" id="edit-checkboxname" although, developers sometimes insert "][" into the checkbox names in order to generate arrays. So the question is this: What is the best way to pass the selector for a column of checkboxes? I'm guessing that a regex will need to be generated for JavaScript to find what it needs, but it'd be nice if this regex could be generated by form_mastercheckbox() rather than having to require developers to get mucked up with regular expressions in order to use the function. Any thoughts are appreciated! -Jeff Robbins jjeff 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/jav... ------------------------------------------------------------------------ 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 ------------------------------------------------------------------------ Mon, 25 Jul 2005 15:14:03 +0000 : Steven +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.
participants (8)
-
Bèr Kessels -
com2
-
factoryjoe
-
jjeff
-
Junyor
-
moshe weitzman
-
nysus
-
Steven