As the options area allows key-value pairs, it would be good if the questions area would allow this also. Most of the work seems to have been done already. The following changes seem to set this right. I tested against a form without key-pairs and it seems to be okay.

function _webform_submit_grid(&$data, $component) {

  $options = drupal_map_assoc(array_flip(_webform_select_options($component['extra']['options'])));
  $questions = array_flip(_webform_select_options($component['extra']['questions']));

  if (is_array($data)) {
    foreach ($data as $key => $value) {
      if ($value) {
        $data2[$questions[$key]] = $options[$value];
      }
    }
    $data = $data2; //need to overwrite the old data.
  }
  elseif (!empty($data)) {
    $data = $options[$data];
  }
}

I can roll a patch later if it is required.

CommentFileSizeAuthor
#8 grid-2.6.patch2.1 KBmk3001
#1 webform5.x-2.1.3-grid_question_keyvalues.patch844 bytessamhassell
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

samhassell’s picture

samhassell CreditAttribution: samhassell commented
FileSize
webform5.x-2.1.3-grid_question_keyvalues.patch844 bytes

Attaching a patch. Note that the patch rolls in a fix from #7 at http://drupal.org/node/285554

samhassell’s picture

samhassell CreditAttribution: samhassell commented

Any chance of getting this feature rolled in? kind of annoying to keep patching webform.

quicksketch’s picture

quicksketch
he/him
CreditAttribution: quicksketch commented

I agree this would be a good thing to get in. I'm always a little tentative about changing the select.inc or grid.inc, as they're prone to error. Hopefully my testing suite in Drupal 6 will prevent any breakage.

I'm curious though, what benefit is gained by this patch, since the "key" of the questions is never stored in the database? Right now, the questions stored by position, unfortunately, not the actual text of the question.

samhassell’s picture

samhassell CreditAttribution: samhassell commented

Ah good question, I'm actually taking the data and storing it in a separate table via the additional processing field. I then have a module which uses that table to prepare a report based on the users answers. The logic in the report makes more sense when we identify things by a key instead of by the actual question text, which may be subject to change.

The table is of the format 'uid | name | value' so we can add and remove questions easily using the webform module. These forms are also multistep, each step with a different tpl.php file (so the multiple page webform would not work)

I see your point though, this code would not be very useful to people unless they were doing something off the beaten track, like I am. Maybe it could be an undocumented feature? When I hit the problem, it seemed logical for this to work, as the other field already does it.

In retrospect, maybe I should have written a wrapper for the existing webform database tables and used that data. Everything needed to do that seems to be in the existing tables.

As a side note, this helps to explain why a few people are looking for a way to turn off webform's storage mechanisms and report display code.

Anyway thanks for an awesome, flexible module. I'm looking forward to v2.x. I love your work and that of the Lullabots. Thanks!

samhassell’s picture

samhassell CreditAttribution: samhassell commented
Status: Needs work » Needs review

If this code gets reviewed, maybe we can get it in. This is still important to me.

quicksketch’s picture

quicksketch
he/him
CreditAttribution: quicksketch commented
Status: Needs review » Needs work

I'm still totally agreed this is a good thing. The grid.inc file received a lot updates in recent versions though, this will need to be updated for the changes.

naught101’s picture

naught101 CreditAttribution: naught101 commented

subscribing, any movement on this over the last month?

mk3001’s picture

mk3001 CreditAttribution: mk3001 commented
Version: 5.x-2.x-dev » 6.x-2.6
FileSize
grid-2.6.patch2.1 KB

Idea is good, but the form use still the large fulltext question

this will prodce long nearly unreadable html code in naming the attributes of the input fields

following patch use keys in form as part for the name attribute

Attaching a patch for 6-2.6.

Amir Simantov’s picture

Amir Simantov CreditAttribution: Amir Simantov commented

Haven't this change been supposed to go to newest version? I was looking for it... (D6)

quicksketch’s picture

quicksketch
he/him
CreditAttribution: quicksketch commented
Version: 6.x-2.6 »

This will likely be incorporated into #712324: Convert Select and Grid Options to New Data Storage in the 3.x version of Webform. 2.x is no longer receiving new features.

zeropaper’s picture

zeropaper CreditAttribution: zeropaper commented

subscribing, looks like a critical need to me (already patched 6-2.6 version ;) ).

quicksketch’s picture

quicksketch
he/him
CreditAttribution: quicksketch commented
Version: » 6.x-3.x-dev
Status: Needs work » Closed (duplicate)

This functionality is being bundled into #712324: Convert Select and Grid Options to New Data Storage, which would actually use these keys for something. Right now adding keys to grid questions doesn't accomplish anything in terms of data integrity.