GSOC 2010 Condition engine

This page is dedicated to the GSOC2010 Condition Engine Project

FAQ

• Will I have to implement an RPN parser?

In fact a first version of an RPN parser has already been integrated to LS2, ask macduy for more details.

• Why is this a difficult project ?

We want a generic condition engine, able to support multiple kind of conditions. The conditions can be based on static values (predefined string or number) or variable values (context dependant values such as a previous answer, or a user-specific value, ...).

We also want to make the GUI as user friendly as possible so that even if we can design complex conditions, simple conditions design doesn't become a hassle.

Moreover, conditions may have several usage in LS2, not only helping design question branching but also helping design assessments and so on. This means that implementing conditions may require a lot of communication between the "condition engine" team and the other LS2 developpers.

• Do I have to understand how LS1 implements conditions ?

Understanding LS1 conditions is important because it will show you what is currently possible to do.

However you don't have to understand how everything is implemented.

Please carefully read The conditions documentation for LS1

I would highly recommend setting several surveys with conditions and see how it works:

- for question per page surveys, for group by group surveys, for all-in-one surveys: note how condition evaluation is either done on the server side, or on the client side

- also try several kind of conditions:

- conditions on previous answer compared to a static value or to another previous answer, conditions on token (user-dependant value),

- understand the difference between a condition using "not answer" and "not displayed" (the latest is not supported in LS1)

- think about a strategy for LS2 to better handle the "Chained conditions" issue and other gotchas from LS1 conditions

• How does the condition engine relates to other parts of the LS2 core ?

Conditions will be used in a variety of ways: question branching, assessments, ...

What this means is that a condition will be mapped to an action.

For instance:

- in a question branching context: map the conditions to the "Display question XXX" action

- in an assessment context: map condition to the "update assessment score YYY by exectuing the following arithmetic operation ..."

For the question branching action, the condition engine, must:

- understand how answers are stored (either in SESSION, in DB or even in the HTML page if the evaluation is done by Javascript)

- understand how to access participant's specific data

- understand how LS2 handles mandatory questions and how to alter this behaviour if the question is hidden

- be able to reset an answer to "No answer" if a previously answered question becomes hidden because the participant changed his mind and modified a previous answer (see the deletenonvalue parameter).