What is the preferred way to set values of variables in the database?

Several of the other threads seem they could benefit from this,so I have upgraded the equation parser to support assigning registered variables within an equation (e.g. a = b, c += d, etc). The unit testing on the equation parser works fine, but all assignment is done locally within the equation parser. To integrate with LimeSurvey, I'll set a dirty flag so that we know which of the registered variables had had their values changed.

So, once I know which of the variables have changed values, how do I ensure that this gets recorded?
(1) Server-Side (PHP) - Do I have to update the database directly?
(2) Client-Side (JavaScript) - If I just update the value of the appropriate DOM object (e.g. document.getElementById("answerSGQA").value = new_value, where SGQA is the SGQA code), will LimeSurvey automatically update the associated database field, or do I need to do something else too?

Hi Tom,

I'm not sure if you propose to be able to change the values of already registered variables such as answers or if you also propose to let the survey admin register his own variabels (which would be IMO a great asset).

For the first case, it is simple:
* make sure your expression evaluation is done before save.php, and then let save.php record to DB as if the input was coming from the web page. Caution: you may only update registered fields that corresponds to questions already seen (they must have been displayed in previous pages).
* in Client-side: just update the DOM element that corresponds to the variable: the DOM name is different when the variable corresponds to a question displayed in the current page or question that has been displayed before.


If you intend to add expression specific variables, then we may let the survey-admin decides if the variable needs to be recorded into DB or not. Then if it is to be recorded to DB we must make it a valid fieldname (see function createFieldmap).

(1) Server-Side: The best way would be to use the same piece of code that is used for answer recording. This is done in save.php. Basically we parse the POST variables and delete variables not in the the authorized variable names list(function createFieldMap returns the list of registered variables).
So the process IMO would be to register the expression-variables to the createFieldMap (this requires special care because the createFieldMap function is used all over LS code, but this may be the cleanest way).
Then in save.php add a piece of code to record expression-variable changed at this step.

This also implies checking the activate.php code (but it uses createFieldMap sot it should create the corresponding variables). However, we can't create expression-variable once the survey is activated.

(2) For Client-Side: we need to POST the value in a DOM object. We thus need to define a naming convention for the new variables names in the DOM and update the retrieveJSidname function.

Just my 10 minutes idea on this very interresting proposal.
Thibault

Thibault-

I was hoping to support the following:
(1) changing answers to questions that had already been asked
(2) changing any read-write LimeReplacementField
(3) changing any read-write Token
(4) letting admins register their own variables

To register the list of valid variables and their values, I'm already taking a read-only copy of createFieldMap($style='full), and populating the current values via retrieve_answer(SGQA). So, sounds like save.php will already manage that subset of the variables.

Is there a consolidated function for retrieving the names and current values of all of the LimeReplacementFields? I see about 100 of them spread across a dozen files.

/Tom

ExpressionManager is now stable in the limesurvey_dev_tms branch. For people wanting to test it, it may be easier to try out that branch rather than dealing with patches to the main branch.

Assuming you install the branch on localhost, the Unit tests are [url=http://localhost/limesurvey_dev_tms/classes/eval/ExpressionManagerTestSuite.php]here[/url]. They show all of the main features (e.g. complex equations, call functions, syntax highlighting when there are syntax errors).

You can also load the attached survey (effectively the Integration tests), which demonstrates how ExpressionManager can be used to compute values, tailor messages based upon those computations, and generate customized reports of questions asked and responses given.

More details about current and planned features can be found at those issue-tracking links.

For those who want a preview of ExpressionManager (but aren't able to download the branch or patch a local install), you can try these links:

(1) Sample Survey - Shows calculations, conditional tailoring of text, and summary of responses before submitting
(2) ExpressionManager Test Suite - shows all of the main functionality, including syntax highlighting when syntax errors are detected.
(3) ExpressionManager Log file - shows table of all current responses for the Sample Survey, dynamically generated from the running survey.

ExpressionManager is now operational in the limesurvey_dev_tms branch. This includes dynamic on-current-page Assessments, Conditions, and tailoring (e.g. change the value of some questions or boilerplate text displays as you type responses to other questions)

More information can be found on the wiki page [url=http://http://docs.limesurvey.org/Expression+Manager]here[/url].

Attached is a 2 page demo of ExpressionManager that shows how it supports dynamic (e.g. on the current page):

1. Calculations, Assessments & Reports - Page 1 shows many math facts for the numbers as you enter them
2. Conditional Relevance (e.g. complex Conditions) with cascading - Page 2 conditionally asks questions about your age, marital status, and number of children, but only showing potentially relevant questions based upon your age and prior responses
3. Conditional Micro-Tailoring - Page 2 provides a running commentary about the information you entered at the bottom of the page
4. Blanking out Non-Applicable (e.g. irrelevant) responses. Page 2 shows that if you first enter an adult age and information about children, then change the entered age to 4, all of the questions that depend upon age get blanked out. This feature is used to support cascading logic in the Relevance equations so that you don't have to attach all relevance criteria to each question.

This functionality (now called Expression Manager) is now working (except for a few small lingering issues listed here). It is even supporting cascading conditions and dynamic computation, branching, assessments, and question generation (tailoring) on the same page.

More details can be found at the Expression Manager documentation page