Re: [phpesp-dev] design thoughts needed: hidden from view, but automatically populated, response

[Bishop B. <ph...@id...>]

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