Issue status update for http://drupal.org/node/30150 Post a follow up: http://drupal.org/project/comments/add/30150 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: Steven Reported by: Steven Updated by: Steven Status: patch (code needs review) Attachment: http://drupal.org/files/issues/jstablesort_0.patch (13.25 KB) Missed a table in statistics.module ;). Steven Previous comments: ------------------------------------------------------------------------ Wed, 31 Aug 2005 22:39:36 +0000 : Steven Attachment: http://drupal.org/files/issues/jstablesort.patch (12.93 KB) This patch adds Ajax-based tablesorting to tablesort.inc. Note that this is /not/ client-side sorting, which isn't that useful in Drupal as most sortable tables are paged. Of course, given that it still requires a round-trip to the server, the biggest advantage is in visual usability, as only the table itself changes and not the entire page. The way this is accomplished will probably strike you as very elegant, or very dirty ;). In order to avoid patching up every instance of a sortable table and providing a custom Ajax menu callback for each, I made it so that inside theme('table'), the tablesort can cause the table to be printed immediately and PHP to quit. This is triggered by the GET variable 'tablesort', when set to the table's id. So, the Ajax HTTP request visits the exact same page as the original page, it only adds something to the URL which triggers this special behaviour. It works really well. In fact, the id-per-table wouldn't be necessary if we restricted ourselves to one sortable table per page.

Issue status update for http://drupal.org/node/30150 Post a follow up: http://drupal.org/project/comments/add/30150 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: Steven Reported by: Steven Updated by: Steven Status: patch (code needs review) The structure just mimics the existing stuff really (like autocomplete.js): the autoattach deals with seeking out suitable targets and installing the event handler. The tablesort object is just there to provide a persistent data storage for handling the asynchronous request. I suppose once we've found a table we could create a tablesort object and then seek out the relevant links and header cells in there, but I don't see a problem with doing that in the autoattach either. Steven Previous comments: ------------------------------------------------------------------------ Wed, 31 Aug 2005 22:39:36 +0000 : Steven Attachment: http://drupal.org/files/issues/jstablesort.patch (12.93 KB) This patch adds Ajax-based tablesorting to tablesort.inc. Note that this is /not/ client-side sorting, which isn't that useful in Drupal as most sortable tables are paged. Of course, given that it still requires a round-trip to the server, the biggest advantage is in visual usability, as only the table itself changes and not the entire page. The way this is accomplished will probably strike you as very elegant, or very dirty ;). In order to avoid patching up every instance of a sortable table and providing a custom Ajax menu callback for each, I made it so that inside theme('table'), the tablesort can cause the table to be printed immediately and PHP to quit. This is triggered by the GET variable 'tablesort', when set to the table's id. So, the Ajax HTTP request visits the exact same page as the original page, it only adds something to the URL which triggers this special behaviour. It works really well. In fact, the id-per-table wouldn't be necessary if we restricted ourselves to one sortable table per page. ------------------------------------------------------------------------ Wed, 31 Aug 2005 23:04:38 +0000 : Steven Attachment: http://drupal.org/files/issues/jstablesort_0.patch (13.25 KB) Missed a table in statistics.module ;). ------------------------------------------------------------------------ Wed, 31 Aug 2005 23:11:35 +0000 : Thox I haven't tested the patch, only glimpsed through it for now. The JS-side seems fine. I'm a little curious why tablesortAutoAttach() does all the hard work, I imagined the tablesort object could do that for itself. +1 on the concept.

Issue status update for http://drupal.org/node/30150 Post a follow up: http://drupal.org/project/comments/add/30150 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: Steven Reported by: Steven Updated by: m3avrck Status: patch (code needs review) Just for clarification, where I am clicking with the mouse (on the actual text to sort the column) I would expect to see a little 'loading' icon there. Right now that little icon is way *toooooo* far away to make that simple connection :) m3avrck Previous comments: ------------------------------------------------------------------------ Wed, 31 Aug 2005 22:39:36 +0000 : Steven Attachment: http://drupal.org/files/issues/jstablesort.patch (12.93 KB) This patch adds Ajax-based tablesorting to tablesort.inc. Note that this is /not/ client-side sorting, which isn't that useful in Drupal as most sortable tables are paged. Of course, given that it still requires a round-trip to the server, the biggest advantage is in visual usability, as only the table itself changes and not the entire page. The way this is accomplished will probably strike you as very elegant, or very dirty ;). In order to avoid patching up every instance of a sortable table and providing a custom Ajax menu callback for each, I made it so that inside theme('table'), the tablesort can cause the table to be printed immediately and PHP to quit. This is triggered by the GET variable 'tablesort', when set to the table's id. So, the Ajax HTTP request visits the exact same page as the original page, it only adds something to the URL which triggers this special behaviour. It works really well. In fact, the id-per-table wouldn't be necessary if we restricted ourselves to one sortable table per page. ------------------------------------------------------------------------ Wed, 31 Aug 2005 23:04:38 +0000 : Steven Attachment: http://drupal.org/files/issues/jstablesort_0.patch (13.25 KB) Missed a table in statistics.module ;). ------------------------------------------------------------------------ Wed, 31 Aug 2005 23:11:35 +0000 : Thox I haven't tested the patch, only glimpsed through it for now. The JS-side seems fine. I'm a little curious why tablesortAutoAttach() does all the hard work, I imagined the tablesort object could do that for itself. +1 on the concept. ------------------------------------------------------------------------ Wed, 31 Aug 2005 23:28:44 +0000 : Steven The structure just mimics the existing stuff really (like autocomplete.js): the autoattach deals with seeking out suitable targets and installing the event handler. The tablesort object is just there to provide a persistent data storage for handling the asynchronous request. I suppose once we've found a table we could create a tablesort object and then seek out the relevant links and header cells in there, but I don't see a problem with doing that in the autoattach either. ------------------------------------------------------------------------ Thu, 01 Sep 2005 21:30:59 +0000 : m3avrck Tried it out on latest HEAD, patch works great! However, the little 'throbber' graphic... with the browser maximized, the graphic was hard to notice on a quickly loading page, since the graphic was so far to the right wasn't easily noticeable what that little 'flash' thing was. I think it would be more usability to move this graphic so that is just right of the text being clicked on (where the up and down arrows are for showing if that is sorted or not). That would make it much more clear as to what the little grahpic is actually about. Otherwise, I say this is ready to commit, and +1 after the throbber issue is fixed :)

Issue status update for http://drupal.org/node/30150 Post a follow up: http://drupal.org/project/comments/add/30150 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: Steven Reported by: Steven Updated by: Bèr Kessels Status: patch (code needs review) I tried this in konqueror 3.4.1 and it works great. I cannot get to test two tables on one page, for I have no clue where (if! ever!) that occurs. steven. A small suggestion for these kind of JS specific patches: set up a page solmewhere where people can test its behaviour. The reason I did not test the JS upload, was because I had no time to set up a meaningfull drupal site with that patch, only to see if konqueror could deal with it. I doubt a lot of people can reasd JS well enough to comment on he code, but peolpe can then easily visit a page to see if it works with Their Strange Browser. Bèr Kessels Previous comments: ------------------------------------------------------------------------ Wed, 31 Aug 2005 22:39:36 +0000 : Steven Attachment: http://drupal.org/files/issues/jstablesort.patch (12.93 KB) This patch adds Ajax-based tablesorting to tablesort.inc. Note that this is /not/ client-side sorting, which isn't that useful in Drupal as most sortable tables are paged. Of course, given that it still requires a round-trip to the server, the biggest advantage is in visual usability, as only the table itself changes and not the entire page. The way this is accomplished will probably strike you as very elegant, or very dirty ;). In order to avoid patching up every instance of a sortable table and providing a custom Ajax menu callback for each, I made it so that inside theme('table'), the tablesort can cause the table to be printed immediately and PHP to quit. This is triggered by the GET variable 'tablesort', when set to the table's id. So, the Ajax HTTP request visits the exact same page as the original page, it only adds something to the URL which triggers this special behaviour. It works really well. In fact, the id-per-table wouldn't be necessary if we restricted ourselves to one sortable table per page. ------------------------------------------------------------------------ Wed, 31 Aug 2005 23:04:38 +0000 : Steven Attachment: http://drupal.org/files/issues/jstablesort_0.patch (13.25 KB) Missed a table in statistics.module ;). ------------------------------------------------------------------------ Wed, 31 Aug 2005 23:11:35 +0000 : Thox I haven't tested the patch, only glimpsed through it for now. The JS-side seems fine. I'm a little curious why tablesortAutoAttach() does all the hard work, I imagined the tablesort object could do that for itself. +1 on the concept. ------------------------------------------------------------------------ Wed, 31 Aug 2005 23:28:44 +0000 : Steven The structure just mimics the existing stuff really (like autocomplete.js): the autoattach deals with seeking out suitable targets and installing the event handler. The tablesort object is just there to provide a persistent data storage for handling the asynchronous request. I suppose once we've found a table we could create a tablesort object and then seek out the relevant links and header cells in there, but I don't see a problem with doing that in the autoattach either. ------------------------------------------------------------------------ Thu, 01 Sep 2005 21:30:59 +0000 : m3avrck Tried it out on latest HEAD, patch works great! However, the little 'throbber' graphic... with the browser maximized, the graphic was hard to notice on a quickly loading page, since the graphic was so far to the right wasn't easily noticeable what that little 'flash' thing was. I think it would be more usability to move this graphic so that is just right of the text being clicked on (where the up and down arrows are for showing if that is sorted or not). That would make it much more clear as to what the little grahpic is actually about. Otherwise, I say this is ready to commit, and +1 after the throbber issue is fixed :) ------------------------------------------------------------------------ Thu, 01 Sep 2005 21:32:44 +0000 : m3avrck Just for clarification, where I am clicking with the mouse (on the actual text to sort the column) I would expect to see a little 'loading' icon there. Right now that little icon is way *toooooo* far away to make that simple connection :) ------------------------------------------------------------------------ Fri, 02 Sep 2005 13:49:05 +0000 : m3avrck For further clarification and after more testing, this is only a problem where columns take up much more of the page width, for example on the logs page and clicking on the 'messages' column. However, playing around with the CSS more I'm not too sure if there is a suitable fix for this, so I'll give this patch a +1 and it works great. Degrades well for users with Javascript disabled.

Issue status update for http://drupal.org/node/30150 Post a follow up: http://drupal.org/project/comments/add/30150 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: Steven Reported by: Steven Updated by: Bèr Kessels Status: patch (code needs review) The clients 'busy' notification not reacting on AJAX is a common usability issue with AJAX. One of many. the back button not working is another *mayor* one. All in all, AJAX is still far from mature and even further from perfect. Still, it serves Drupals usability quite well. More about AJAX usability drawbacks here: http://sourcelabs.com/ajb/archives/2005/05/ajax_mistakes.html and http://www.baekdal.com/articles/Usability/XMLHttpRequest-guidelines/ Bèr Kessels Previous comments: ------------------------------------------------------------------------ Wed, 31 Aug 2005 22:39:36 +0000 : Steven Attachment: http://drupal.org/files/issues/jstablesort.patch (12.93 KB) This patch adds Ajax-based tablesorting to tablesort.inc. Note that this is /not/ client-side sorting, which isn't that useful in Drupal as most sortable tables are paged. Of course, given that it still requires a round-trip to the server, the biggest advantage is in visual usability, as only the table itself changes and not the entire page. The way this is accomplished will probably strike you as very elegant, or very dirty ;). In order to avoid patching up every instance of a sortable table and providing a custom Ajax menu callback for each, I made it so that inside theme('table'), the tablesort can cause the table to be printed immediately and PHP to quit. This is triggered by the GET variable 'tablesort', when set to the table's id. So, the Ajax HTTP request visits the exact same page as the original page, it only adds something to the URL which triggers this special behaviour. It works really well. In fact, the id-per-table wouldn't be necessary if we restricted ourselves to one sortable table per page. ------------------------------------------------------------------------ Wed, 31 Aug 2005 23:04:38 +0000 : Steven Attachment: http://drupal.org/files/issues/jstablesort_0.patch (13.25 KB) Missed a table in statistics.module ;). ------------------------------------------------------------------------ Wed, 31 Aug 2005 23:11:35 +0000 : Thox I haven't tested the patch, only glimpsed through it for now. The JS-side seems fine. I'm a little curious why tablesortAutoAttach() does all the hard work, I imagined the tablesort object could do that for itself. +1 on the concept. ------------------------------------------------------------------------ Wed, 31 Aug 2005 23:28:44 +0000 : Steven The structure just mimics the existing stuff really (like autocomplete.js): the autoattach deals with seeking out suitable targets and installing the event handler. The tablesort object is just there to provide a persistent data storage for handling the asynchronous request. I suppose once we've found a table we could create a tablesort object and then seek out the relevant links and header cells in there, but I don't see a problem with doing that in the autoattach either. ------------------------------------------------------------------------ Thu, 01 Sep 2005 21:30:59 +0000 : m3avrck Tried it out on latest HEAD, patch works great! However, the little 'throbber' graphic... with the browser maximized, the graphic was hard to notice on a quickly loading page, since the graphic was so far to the right wasn't easily noticeable what that little 'flash' thing was. I think it would be more usability to move this graphic so that is just right of the text being clicked on (where the up and down arrows are for showing if that is sorted or not). That would make it much more clear as to what the little grahpic is actually about. Otherwise, I say this is ready to commit, and +1 after the throbber issue is fixed :) ------------------------------------------------------------------------ Thu, 01 Sep 2005 21:32:44 +0000 : m3avrck Just for clarification, where I am clicking with the mouse (on the actual text to sort the column) I would expect to see a little 'loading' icon there. Right now that little icon is way *toooooo* far away to make that simple connection :) ------------------------------------------------------------------------ Fri, 02 Sep 2005 13:49:05 +0000 : m3avrck For further clarification and after more testing, this is only a problem where columns take up much more of the page width, for example on the logs page and clicking on the 'messages' column. However, playing around with the CSS more I'm not too sure if there is a suitable fix for this, so I'll give this patch a +1 and it works great. Degrades well for users with Javascript disabled. ------------------------------------------------------------------------ Sat, 03 Sep 2005 22:49:52 +0000 : Bèr Kessels I tried this in konqueror 3.4.1 and it works great. I cannot get to test two tables on one page, for I have no clue where (if! ever!) that occurs. steven. A small suggestion for these kind of JS specific patches: set up a page solmewhere where people can test its behaviour. The reason I did not test the JS upload, was because I had no time to set up a meaningfull drupal site with that patch, only to see if konqueror could deal with it. I doubt a lot of people can reasd JS well enough to comment on he code, but peolpe can then easily visit a page to see if it works with Their Strange Browser. ------------------------------------------------------------------------ Sun, 04 Sep 2005 16:51:18 +0000 : Dries I tried this patch but I don't see a throbber? My natural reaction is to check Firefox's throbber. Also, I'm not convinced it is a good idea to trade usability for performance.

Issue status update for http://drupal.org/node/30150 Post a follow up: http://drupal.org/project/comments/add/30150 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: Steven Reported by: Steven Updated by: Bèr Kessels Status: patch (code needs review) I really like that route, Jose. It gets a +1 from me. Provided we ship with one advanced theme that uses all these things. Bèr Kessels Previous comments: ------------------------------------------------------------------------ Wed, 31 Aug 2005 22:39:36 +0000 : Steven Attachment: http://drupal.org/files/issues/jstablesort.patch (12.93 KB) This patch adds Ajax-based tablesorting to tablesort.inc. Note that this is /not/ client-side sorting, which isn't that useful in Drupal as most sortable tables are paged. Of course, given that it still requires a round-trip to the server, the biggest advantage is in visual usability, as only the table itself changes and not the entire page. The way this is accomplished will probably strike you as very elegant, or very dirty ;). In order to avoid patching up every instance of a sortable table and providing a custom Ajax menu callback for each, I made it so that inside theme('table'), the tablesort can cause the table to be printed immediately and PHP to quit. This is triggered by the GET variable 'tablesort', when set to the table's id. So, the Ajax HTTP request visits the exact same page as the original page, it only adds something to the URL which triggers this special behaviour. It works really well. In fact, the id-per-table wouldn't be necessary if we restricted ourselves to one sortable table per page. ------------------------------------------------------------------------ Wed, 31 Aug 2005 23:04:38 +0000 : Steven Attachment: http://drupal.org/files/issues/jstablesort_0.patch (13.25 KB) Missed a table in statistics.module ;). ------------------------------------------------------------------------ Wed, 31 Aug 2005 23:11:35 +0000 : Thox I haven't tested the patch, only glimpsed through it for now. The JS-side seems fine. I'm a little curious why tablesortAutoAttach() does all the hard work, I imagined the tablesort object could do that for itself. +1 on the concept. ------------------------------------------------------------------------ Wed, 31 Aug 2005 23:28:44 +0000 : Steven The structure just mimics the existing stuff really (like autocomplete.js): the autoattach deals with seeking out suitable targets and installing the event handler. The tablesort object is just there to provide a persistent data storage for handling the asynchronous request. I suppose once we've found a table we could create a tablesort object and then seek out the relevant links and header cells in there, but I don't see a problem with doing that in the autoattach either. ------------------------------------------------------------------------ Thu, 01 Sep 2005 21:30:59 +0000 : m3avrck Tried it out on latest HEAD, patch works great! However, the little 'throbber' graphic... with the browser maximized, the graphic was hard to notice on a quickly loading page, since the graphic was so far to the right wasn't easily noticeable what that little 'flash' thing was. I think it would be more usability to move this graphic so that is just right of the text being clicked on (where the up and down arrows are for showing if that is sorted or not). That would make it much more clear as to what the little grahpic is actually about. Otherwise, I say this is ready to commit, and +1 after the throbber issue is fixed :) ------------------------------------------------------------------------ Thu, 01 Sep 2005 21:32:44 +0000 : m3avrck Just for clarification, where I am clicking with the mouse (on the actual text to sort the column) I would expect to see a little 'loading' icon there. Right now that little icon is way *toooooo* far away to make that simple connection :) ------------------------------------------------------------------------ Fri, 02 Sep 2005 13:49:05 +0000 : m3avrck For further clarification and after more testing, this is only a problem where columns take up much more of the page width, for example on the logs page and clicking on the 'messages' column. However, playing around with the CSS more I'm not too sure if there is a suitable fix for this, so I'll give this patch a +1 and it works great. Degrades well for users with Javascript disabled. ------------------------------------------------------------------------ Sat, 03 Sep 2005 22:49:52 +0000 : Bèr Kessels I tried this in konqueror 3.4.1 and it works great. I cannot get to test two tables on one page, for I have no clue where (if! ever!) that occurs. steven. A small suggestion for these kind of JS specific patches: set up a page solmewhere where people can test its behaviour. The reason I did not test the JS upload, was because I had no time to set up a meaningfull drupal site with that patch, only to see if konqueror could deal with it. I doubt a lot of people can reasd JS well enough to comment on he code, but peolpe can then easily visit a page to see if it works with Their Strange Browser. ------------------------------------------------------------------------ Sun, 04 Sep 2005 16:51:18 +0000 : Dries I tried this patch but I don't see a throbber? My natural reaction is to check Firefox's throbber. Also, I'm not convinced it is a good idea to trade usability for performance. ------------------------------------------------------------------------ Sun, 04 Sep 2005 20:51:26 +0000 : Bèr Kessels The clients 'busy' notification not reacting on AJAX is a common usability issue with AJAX. One of many. the back button not working is another *mayor* one. All in all, AJAX is still far from mature and even further from perfect. Still, it serves Drupals usability quite well. More about AJAX usability drawbacks here: http://sourcelabs.com/ajb/archives/2005/05/ajax_mistakes.html and http://www.baekdal.com/articles/Usability/XMLHttpRequest-guidelines/ ------------------------------------------------------------------------ Mon, 05 Sep 2005 14:17:14 +0000 : Jose A Reyero Couldn't we just provide this as a library to be used by themes, and then leave the default theme functions free of this stuff?

Issue status update for http://drupal.org/node/30150 Post a follow up: http://drupal.org/project/comments/add/30150 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: Steven Reported by: Steven Updated by: Dries Status: patch (code needs review) The more I think about AJAX based tablesorting, the less sense it makes. It improves performance but introduces complexity and usability quircks. Dries Previous comments: ------------------------------------------------------------------------ Wed, 31 Aug 2005 22:39:36 +0000 : Steven Attachment: http://drupal.org/files/issues/jstablesort.patch (12.93 KB) This patch adds Ajax-based tablesorting to tablesort.inc. Note that this is /not/ client-side sorting, which isn't that useful in Drupal as most sortable tables are paged. Of course, given that it still requires a round-trip to the server, the biggest advantage is in visual usability, as only the table itself changes and not the entire page. The way this is accomplished will probably strike you as very elegant, or very dirty ;). In order to avoid patching up every instance of a sortable table and providing a custom Ajax menu callback for each, I made it so that inside theme('table'), the tablesort can cause the table to be printed immediately and PHP to quit. This is triggered by the GET variable 'tablesort', when set to the table's id. So, the Ajax HTTP request visits the exact same page as the original page, it only adds something to the URL which triggers this special behaviour. It works really well. In fact, the id-per-table wouldn't be necessary if we restricted ourselves to one sortable table per page. ------------------------------------------------------------------------ Wed, 31 Aug 2005 23:04:38 +0000 : Steven Attachment: http://drupal.org/files/issues/jstablesort_0.patch (13.25 KB) Missed a table in statistics.module ;). ------------------------------------------------------------------------ Wed, 31 Aug 2005 23:11:35 +0000 : Thox I haven't tested the patch, only glimpsed through it for now. The JS-side seems fine. I'm a little curious why tablesortAutoAttach() does all the hard work, I imagined the tablesort object could do that for itself. +1 on the concept. ------------------------------------------------------------------------ Wed, 31 Aug 2005 23:28:44 +0000 : Steven The structure just mimics the existing stuff really (like autocomplete.js): the autoattach deals with seeking out suitable targets and installing the event handler. The tablesort object is just there to provide a persistent data storage for handling the asynchronous request. I suppose once we've found a table we could create a tablesort object and then seek out the relevant links and header cells in there, but I don't see a problem with doing that in the autoattach either. ------------------------------------------------------------------------ Thu, 01 Sep 2005 21:30:59 +0000 : m3avrck Tried it out on latest HEAD, patch works great! However, the little 'throbber' graphic... with the browser maximized, the graphic was hard to notice on a quickly loading page, since the graphic was so far to the right wasn't easily noticeable what that little 'flash' thing was. I think it would be more usability to move this graphic so that is just right of the text being clicked on (where the up and down arrows are for showing if that is sorted or not). That would make it much more clear as to what the little grahpic is actually about. Otherwise, I say this is ready to commit, and +1 after the throbber issue is fixed :) ------------------------------------------------------------------------ Thu, 01 Sep 2005 21:32:44 +0000 : m3avrck Just for clarification, where I am clicking with the mouse (on the actual text to sort the column) I would expect to see a little 'loading' icon there. Right now that little icon is way *toooooo* far away to make that simple connection :) ------------------------------------------------------------------------ Fri, 02 Sep 2005 13:49:05 +0000 : m3avrck For further clarification and after more testing, this is only a problem where columns take up much more of the page width, for example on the logs page and clicking on the 'messages' column. However, playing around with the CSS more I'm not too sure if there is a suitable fix for this, so I'll give this patch a +1 and it works great. Degrades well for users with Javascript disabled. ------------------------------------------------------------------------ Sat, 03 Sep 2005 22:49:52 +0000 : Bèr Kessels I tried this in konqueror 3.4.1 and it works great. I cannot get to test two tables on one page, for I have no clue where (if! ever!) that occurs. steven. A small suggestion for these kind of JS specific patches: set up a page solmewhere where people can test its behaviour. The reason I did not test the JS upload, was because I had no time to set up a meaningfull drupal site with that patch, only to see if konqueror could deal with it. I doubt a lot of people can reasd JS well enough to comment on he code, but peolpe can then easily visit a page to see if it works with Their Strange Browser. ------------------------------------------------------------------------ Sun, 04 Sep 2005 16:51:18 +0000 : Dries I tried this patch but I don't see a throbber? My natural reaction is to check Firefox's throbber. Also, I'm not convinced it is a good idea to trade usability for performance. ------------------------------------------------------------------------ Sun, 04 Sep 2005 20:51:26 +0000 : Bèr Kessels The clients 'busy' notification not reacting on AJAX is a common usability issue with AJAX. One of many. the back button not working is another *mayor* one. All in all, AJAX is still far from mature and even further from perfect. Still, it serves Drupals usability quite well. More about AJAX usability drawbacks here: http://sourcelabs.com/ajb/archives/2005/05/ajax_mistakes.html and http://www.baekdal.com/articles/Usability/XMLHttpRequest-guidelines/ ------------------------------------------------------------------------ Mon, 05 Sep 2005 14:17:14 +0000 : Jose A Reyero Couldn't we just provide this as a library to be used by themes, and then leave the default theme functions free of this stuff? ------------------------------------------------------------------------ Mon, 05 Sep 2005 15:56:34 +0000 : Bèr Kessels I really like that route, Jose. It gets a +1 from me. Provided we ship with one advanced theme that uses all these things. ------------------------------------------------------------------------ Thu, 15 Sep 2005 18:35:54 +0000 : m3avrck Dries how is the performance degraded on this? Makes things *very* nice IMO didn't see a performance hit (probably overlooked something).