From: Bishop B. <ph...@id...> - 2008-01-10 23:19:49
|
All, Suppose you want to cross-tabulate respondent last name versus a =20 question on your survey, to answer say something like "How many =20 Smith's said their household income was too low?" Right now, you have to ask the user their last name, because the =20 cross-tabulation works against the survey data, not against the =20 respondent data. You've already got the user's information, so why =20 ask for it? Yes, this example is contrived. But, this scenario stems from a =20 particular need of mine, where I'm actually augmenting the respondent =20 data with age, gender, ethnicity, etc. and I want to be able to use =20 the built-in cross-tabulation functionality against those metrics: =20 "How many women answered yes to question 1?" The idea I've come up with is to have "hidden" survey fields, similar =20 to hidden input elements in HTML. The survey would have place holders =20 for the value, but when the respondent logs in, those input elements =20 aren't seen but are populated from a data source. To implement this, I would add a new type to the question type =20 drop-down called "hidden". The name would be required, as usual. The =20 text would either static text or a template variable. so, you might have this: Name =3D Q1 Type =3D Hidden Text =3D foo Which would render as <input type=3D"hidden" name=3D"Q1" value=3D"foo" /> For my particular need, I'd put in template variable aliases (a la =20 Smarty) for respondent, etc. so that data could be accessed: Name =3D Q1 Type =3D Hidden Text =3D $respondent.gender Like executing this: <input type=3D"hidden" name=3D"Q1" value=3D"<?=3D $respondent['gender'] ?>" = /> Yielding after rendering, e.g: <input type=3D"hidden" name=3D"Q1" value=3D"M" /> Thoughts? bishop --=20 Bishop Bettini ideacode, Inc. (main) +1 919 341 5170 / (fax) +1 919 521 4100 Visit us on the web at: ideacode.com Professional software research and development reviewmysoftware.com Improve sales! Review your software before you release bytejar.com Solutions to those annoying development problems |
From: Matthew G. <mat...@gm...> - 2008-01-11 00:55:40
|
I like the idea of a hidden text field question type. Are you planning on making all respondent data available as in a $respondent['foo'] variable? Wonder if a "respondent data question type" with a drop down to select which bit of respondent data you want, would be better? Don't forget to switch from CVS HEAD to SVN trunk. I've committed favicon patch and hopefully the other changes you sent soon. On Thu, 2008-01-10 at 18:19 -0500, Bishop Bettini wrote: > All, > > Suppose you want to cross-tabulate respondent last name versus a > question on your survey, to answer say something like "How many > Smith's said their household income was too low?" > > Right now, you have to ask the user their last name, because the > cross-tabulation works against the survey data, not against the > respondent data. You've already got the user's information, so why > ask for it? > > Yes, this example is contrived. But, this scenario stems from a > particular need of mine, where I'm actually augmenting the respondent > data with age, gender, ethnicity, etc. and I want to be able to use > the built-in cross-tabulation functionality against those metrics: > "How many women answered yes to question 1?" > > The idea I've come up with is to have "hidden" survey fields, similar > to hidden input elements in HTML. The survey would have place holders > for the value, but when the respondent logs in, those input elements > aren't seen but are populated from a data source. > > To implement this, I would add a new type to the question type > drop-down called "hidden". The name would be required, as usual. The > text would either static text or a template variable. > > so, you might have this: > > Name = Q1 > Type = Hidden > Text = foo > > Which would render as > <input type="hidden" name="Q1" value="foo" /> > > For my particular need, I'd put in template variable aliases (a la > Smarty) for respondent, etc. so that data could be accessed: > > Name = Q1 > Type = Hidden > Text = $respondent.gender > > Like executing this: > <input type="hidden" name="Q1" value="<?= $respondent['gender'] ?>" /> > > Yielding after rendering, e.g: > <input type="hidden" name="Q1" value="M" /> > > > Thoughts? > > bishop > |
From: Bishop B. <ph...@id...> - 2008-01-11 14:33:35
|
Matthew, I like your idea of a "respondent data" question type, as I =20 think it's more usable. But let me elaborate my requirement further =20 to explain why I suggested just a "hidden" type with "template =20 variables": I need to include respondent data as well as what I'll call "survey =20 data". The survey itself has information associated with it that is =20 independent of the person completing the survey, but tied directly to =20 the survey itself. For example, person A might have two surveys to complete: one for =20 class A and one for class B. I want the survey for class A to include =20 this fact as part of the survey data, so that I can cross tabulate to =20 answer questions like: "How many men from class B answered 'No' to question 2?" men =3D respondent data class B =3D survey data No =3D response data So I'd like to add two hidden fields, like this: name =3D qA type =3D hidden text =3D $respondent.gender name =3D qB type =3D hidden text =3D classB So when I get the survey back, I've got that data submitted and =20 everything else works as its supposed to. This is probably less =20 usable, as it requires knowledge about what "template variables" are =20 available, but I think it's more flexible. To answer your question, =20 yes, I would think that all respondent columns would be available =20 (including ID and password). Now, here's one rub, based on that last sentence: it's a security hole =20 to pass back this "hidden" data, because the user can craft it to be =20 "incorrect" for their situation. For example, Jane Cracker sees that =20 we're passing back gender =3D "F" as part of her survey. She's devious, =20 so she wants to change that. She hops over to wget and posts her =20 responses such that gender =3D "M". Thus, forging her data. Perhaps a better way to implement this would be: 1. At survey render time, generate a random, whole number integer key. 2. Store the hidden data for the survey into a table with the given key. 3. Render the survey, including only the key as a hidden variable. 4. After post back, lookup the hidden values using the posted key. 5. array_merge the tabled hidden data into $_POST 6. Delete the tabled data Thoughts? bishop Quoting Matthew Gregg <mat...@gm...>: > I like the idea of a hidden text field question type. > > Are you planning on making all respondent data available as in a > $respondent['foo'] variable? Wonder if a "respondent data question > type" with a drop down to select which bit of respondent data you want, > would be better? > > Don't forget to switch from CVS HEAD to SVN trunk. I've committed > favicon patch and hopefully the other changes you sent soon. > > On Thu, 2008-01-10 at 18:19 -0500, Bishop Bettini wrote: >> All, >> >> Suppose you want to cross-tabulate respondent last name versus a >> question on your survey, to answer say something like "How many >> Smith's said their household income was too low?" >> >> Right now, you have to ask the user their last name, because the >> cross-tabulation works against the survey data, not against the >> respondent data. You've already got the user's information, so why >> ask for it? >> >> Yes, this example is contrived. But, this scenario stems from a >> particular need of mine, where I'm actually augmenting the respondent >> data with age, gender, ethnicity, etc. and I want to be able to use >> the built-in cross-tabulation functionality against those metrics: >> "How many women answered yes to question 1?" >> >> The idea I've come up with is to have "hidden" survey fields, similar >> to hidden input elements in HTML. The survey would have place holders >> for the value, but when the respondent logs in, those input elements >> aren't seen but are populated from a data source. >> >> To implement this, I would add a new type to the question type >> drop-down called "hidden". The name would be required, as usual. The >> text would either static text or a template variable. >> >> so, you might have this: >> >> Name =3D Q1 >> Type =3D Hidden >> Text =3D foo >> >> Which would render as >> <input type=3D"hidden" name=3D"Q1" value=3D"foo" /> >> >> For my particular need, I'd put in template variable aliases (a la >> Smarty) for respondent, etc. so that data could be accessed: >> >> Name =3D Q1 >> Type =3D Hidden >> Text =3D $respondent.gender >> >> Like executing this: >> <input type=3D"hidden" name=3D"Q1" value=3D"<?=3D $respondent['gender'] ?= >" /> >> >> Yielding after rendering, e.g: >> <input type=3D"hidden" name=3D"Q1" value=3D"M" /> >> >> >> Thoughts? >> >> bishop >> > > > ------------------------------------------------------------------------- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketpla= ce > _______________________________________________ > phpESP-devel mailing list > php...@li... > https://lists.sourceforge.net/lists/listinfo/phpesp-devel > --=20 Bishop Bettini ideacode, Inc. (main) +1 919 341 5170 / (fax) +1 919 521 4100 Visit us on the web at: ideacode.com Professional software research and development reviewmysoftware.com Improve sales! Review your software before you release bytejar.com Solutions to those annoying development problems |