Closed (duplicate)
Project:
Webform
Version:
6.x-3.x-dev
Component:
Code
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
29 Aug 2008 at 07:25 UTC
Updated:
14 Mar 2010 at 04:08 UTC
Jump to comment: Most recent file
Comments
Comment #1
samhassell commentedAttaching a patch. Note that the patch rolls in a fix from #7 at http://drupal.org/node/285554
Comment #2
samhassell commentedAny chance of getting this feature rolled in? kind of annoying to keep patching webform.
Comment #3
quicksketchI 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.
Comment #4
samhassell commentedAh 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!
Comment #5
samhassell commentedIf this code gets reviewed, maybe we can get it in. This is still important to me.
Comment #6
quicksketchI'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.
Comment #7
naught101 commentedsubscribing, any movement on this over the last month?
Comment #8
mk3001 commentedIdea 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.
Comment #9
amir simantov commentedHaven't this change been supposed to go to newest version? I was looking for it... (D6)
Comment #11
quicksketchThis 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.
Comment #12
zeropapersubscribing, looks like a critical need to me (already patched 6-2.6 version ;) ).
Comment #13
quicksketchThis 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.