Extension:QPoll/Developing scripts

qpuserchoice parser function
This function can be used to extract the answer (user's category choice(s)) of some previously submitted poll. Possible parameters are:
 * poll_address : mandatory. the same as in the poll dependance attribute, given without double quotes.
 * question_id : mandatory, number, starting from 1.
 * proposal_id : mandatory, number, starting from 0.
 * default_answer : optional. if given, returns it's value when categoryX_answer was not given. If omitted or has a blank value, returns category_X_answer in case it's present in the list of parameters, otherwise returns the name of category number X for the current user, poll_address, question_id, proposal_id. Since v0.4.2, this parameter may optionally have special value  $  which indicates that number of category (counting from 0) choosen by current user, will be returned instead (in case the user had answered to the polls question). User selected numbers of categories of particular question can be used in template to calculate overall results (for example, in psychological tests).
 * categoryX_answer : optional, (X: 0..N). If given, returns it's value when category X was chosen by current user in poll_address, question_id, proposal_id. In case the value is blank or omitted, returns the text answer (in case it's not blank), or just the name of category number X for the current user, poll_address, question_id, proposal_id.

Category names of checkboxes "[]" and radiobuttons "" are treated as pre-defined (fixed) user proposal answers. Textfields "<>" may have "custom" texts of the user proposal answers (non-blank field).

Since v0.6.1, #iferror parser function may be used to detect non-existent / non-voted poll and to display a specified message in such case.

See an example below.

General introduction
Since v0.8.0 it's possible to analyze user-submitted poll form values via server-side scripts. Such interpretation scripts can validate user input, and either reject to store invalid user input (no poll voting data will be written into DB in such case) or to display calculated results (for example to implement real psychological or language tests). To edit and store such server-side scripts, new namespace is registered by extension: Interpretation:YourScriptName Script created at Interpretation:YourScriptName page should be usual php code, enclosed into qpinterpret xml tag: ... Because no feature-rich editor is provided yet, it's better to use your favorite editor like vim or notepad++ then copy / paste text inside enclosure.

 ...
 * To bind an existing poll to newly created interpretation script, interpretation attribute should be added to qpoll definition header:
 * Optional max_attempts attribute allows to limit number of poll answer submissions by current user. Such feature might be very useful for education tests.

All of usual poll / question / proposal / category attributes can be used to define poll forms. Users are encouraged to use question "name" attribute and proposal "name" attribute to make interpretation scripts code cleaner and simplier.

Technical details of interpretation

 * Currently scripts are executed in limited subset of PHP language, with (most of) dangerous built-in functions and classes being disallowed via php tokenizer. However, wise admin probably should restrict access 'read' / 'edit' rights of 'NS_QP_INTERPRETATION' and 'NS_QP_INTERPRETATION_TALK' namespaces to sysops and bureaucrats only. Ordinary users and especially anonymous should be disallowed from looking at scripts code.
 * Syntax is checked via php lint when page in Interpretation namespace is saved. In case of errors these will be reported at the top of the page, usually with line number provided for convenience.

There are plans to create Lua-bindings interpretation backend in the future.