UMN Usability / DROP: Make drag and drop save button conditional
catch - February 25, 2008 - 23:24
| Project: | Content Construction Kit (CCK) |
| Version: | 6.x-1.x-dev |
| Component: | Usability |
| Category: | task |
| Priority: | normal |
| Assigned: | ximo |
| Status: | closed |
Description
The "Save" button at admin/content/node-type/[type]/fields is only relevant if you've dragged and dropped some fields.
This task is to add a bit of javascript to hide the button until drag and drop has taken place on the page (so it'll be shown along with the "your changes will only be saved message", and only then). We only want to conditionally hide the button with javascript, so that it shows if js is disabled, not the other way 'round.
#1
#2
True, never occurred to me :-)
tabledrag.js has everything ready for us (see Drupal.tableDrag.prototype.row.prototype.onSwap)
#3
#4
I've claimed this task, and have made a working patch.
I based my code on block.js, as recommended in tabledrag.js.
onSwap would show the Save button before the warning message was shown, so I used onDrop instead. In order to know that the table really had been changed, I used onSwap to set a variable to true.
So much (relatively) JavaScript was required that it couldn't be easily injected inline, so I made a content.js file and put it there. I don't know if you would want to have a .js file for all CCK's JavaScript. Alternatively, I could compress this JS and include it inline - however it would make maintenance difficult.
The content.js file contains console.log() functions so that you may see when it fires using Firebug.
Btw, I noticed that weight elements in the table are textfields and not selects when JS is turned off... I guess you're not done with the form yet :)
#5
Thanks ximo !
Adding a new content.js is perfictly fine IMO. It should see other additions shortly anyway.
Is the
tableChanged = true;flag really needed ? Tabledrag.js already sets its own(see
self.changed = true;inDrupal.tableDrag.prototype.dropRow).Strangely enough, the 'Save' button on my 'Manage fields' tab has the id #edit-submit-1, instead of #edit-submit as expected in your patch..
And the search box's 'Search' button is #edit-submit-2.
Are form element id's unpredictable, by any chance ?
If so, we should probably add a specific class to our 'Save' button, and use that class in the jQuery selector instead.
Aside from this, the patch seems to work perfectly well.
#6
///Are form element id's unpredictable, by any chance ?
Yep. A patch went in somewhere to ensure unique ids for everything - any chance there's two id="edit-submit" on that page? Class as a selector sounds great to avoid this inconsistency though.
#7
I didn't notice the
self.changedflag - thanks! The JS code looks much better now. I also removed thetablevariable which was left by mistake, as well as theconsole.log().. now that you've seen that it works.A class name of
content-admin-field-overview-submit(long, but precise) has been added to the Save button, and is now used to reference the button from JS.You may also want to place the
drupal_add_js()call that loads content.js somewhere more appropriate if you intend to use the file for other purposes.#8
Committed. I simply moved the line that adds the class into the theme function, since this is also where we add the js calls that use it.
Thanks !
#9
Automatically closed -- issue fixed for two weeks with no activity.