Drag and drop in poll module
dmitrig01 - November 17, 2007 - 17:46
| Project: | Drupal |
| Version: | 7.x-dev |
| Component: | poll.module |
| Category: | feature request |
| Priority: | normal |
| Assigned: | quicksketch |
| Status: | active |
Description
Almost working patch attached - drag and drop poll module!
This patch changes a lot of lines because I needed to add a "weight" field to the form (which *should* have been there before)...
| Attachment | Size |
|---|---|
| poll-drag-drop.patch | 9.85 KB |
#1
subscribing.
#2
Well I hit this one hard to try to get it completed. Unfortunately, adding ordering was not as easy as anticipated. Sorting the table rows was easy, but saving the values was another matter. Because poll module actually used the choice position (chorder column) as the key for saving results, rearranging the choices was not a safe or efficient thing to do.
This patch adds drag and drop, and also the necessary database change to support this rearranging:
- The 'chorder' column is converted to 'weight', since it no longer is the exact position for a choice.
- The 'chid' column is added to the poll_votes table and is used as the key for joining, rather than chorder.
Conveniently, a primary key was added to the poll_choices table when the schema changes went in, even though this key wasn't being used for anything. Now it is. :)
I tested this pretty well, and running an upgrade path from 5 to 6 with several polls and thousands of votes pre-registered. Browser checked in Opera, Safari, and Firefox.
#3
This patch sets the weight column to size = 'tiny' and fixes a spacing issue
'#parents' => array('choice', $key,'chtext'),becomes'#parents' => array('choice', $key, 'chtext'),.#4
Nice! This is ready to... :-)
#5
Just to note both this and the upload patch claim system_update_40 - should one or both be rerolled assuming the other also gets in? We're short for time now.
#6
Coming with multiple database changes, I hand this off to Dries for consideration. I was asked to stand by the exception list.
#7
Reroll to make this system_update_6041() after upload module changes.
#8
Poll module might have gotten the pocket-veto for D6, but just in case this patch adds table checks for poll_votes and poll_choices in the system update, similar to the followup patch for upload.
#9
Unfortunately, this
- adds new functionality to polls (ordering was never possible)
- changes much more in the database then what the upload did
So I need to postpone this for Drupal 7. Please understand that we try to focus on fixing what is already there in Drupal 6 and we have gone quite far with drag and drop support anyway. Let's focus on what we have there, and do not introduce new features. As far as I know, we added drag and drop to all orderable lists to wherever it was possible, and we even made uploads orderable, although they were never orderable before. Get this in early in Drupal 7.
Polls are in need of other improvements anyways. While you can add options, and even modify poll counts, you cannot remove items them for example. This shows even more when an ordering feature is added.
#10
#11
No problems Gábor, I agree with the decision here. It would have been possible to change the schema less and simply add another weight column in poll module as we did with upload, but it wasn't the clean fix. Poll module is still in need of some pretty substantial changes, but we significantly improved it during this release cycle so we can be happy with that. :)
Marking CNW since it'll definitely need changing when development opens for 7 again. Thanks!
#12
Poll module is back baby :)
Here's a reroll for Drupal 7. Still fixes the database schema to use (the previously unused) chid auto-increment column instead of the position in the list of questions.
Even if Poll gets removed from core, I wouldn't be offended. But while it's here and we have a fix, might as well get it done.
#13
The poll module is not going to get removed from core.
I don't think the attached patch is correct: the weight field is missing from the database scheme upon a fresh install?
#14
Thanks Dries. "chorder" definitely needed to be renamed to "weight". I didn't re-roll the patch quite right. Here's one that works on a clean install of Drupal and an upgraded D6 site.
#15
I think this looks OK, except for the choice number on the form. It's somewhat odd/silly to show the choice number. Otherwise looks great.
#16
I have hidden the choice numbers. Note that on a new installation I found it necessary to clear the cached data before this change takes effect.
The drag and drop operation is working great!
#17
We need to remove the JS that affected the reordering of these numbers also.
+ // 1. Change the button title to reflect the behavior when using JavaScript.+ // 2. Reorder the choice count when table rows are swapped.
+ drupal_add_js('if (Drupal.jsEnabled) {
+ $(document).ready(function() {
+ $("#edit-poll-more").val("'. t('Add another choice') .'");
+ Drupal.tableDrag["poll-choice-table"].row.prototype.onSwap = function() {
+ $("#poll-choice-table span.choice-number").each(function(n) { $(this).text((n+1) + ".") });
+ };
+ });
+ }', 'inline');
#18
Great point. Now choice number is not being used at all. I have removed the choice number rather than simply hiding it and accordingly I changed the CSS class name to "choice-flag".
#19
Committed to CVS HEAD. :-)
#20
Automatically closed -- issue fixed for two weeks with no activity.
#21
I'm sorry to reopen that issue, but I need some clarifications on changes introduced in this patch.
More precisely,
$poll->choiceis now keyed bychidand so are poll edit and poll vote forms. That means the key is no longer relative but is now shared between all polls. You can't easily reference the first choice of a poll anymore.This caused issue in testing, because we don't have yet a mechanism to pull form choices outside of a form. A patch was committed to fix poll.test a while ago [1], but it's nothing more than a mere hack: we just hope that the choice ids will come out the way we want them to.
Is there a way to change that behavior and to use node-relative keying instead of absolute keying there? After all the natural primary key of
{poll_choice}is (nid,weight).[1] http://drupal.org/node/260492