Conditions Engine

   The storage of conditions will be kept separate from DBSE.  It will only contact the DBSE for getting answers, etc. Similarly, DBSE will contact Conditions Manager to inform of changes to questions, answers, etc.

Database tables

There will be three tables in the database to store conditions. They are: conditions, actions, conditions_actions.

1.    Conditions table: It will store conditions in RPN format.
2.    Actions table: It will store actions.
3.    Conditions_actions table: It will connect the conditions to the actions through IDs.

Operands

1.    All operands will be stored as operand plug-in classes. Some data on them will be stored in an operand table.
2.    Syntax of a stored operand: Datatype_Property1_Property2 (serialized form of  operand class) e.g. PQ_1234. Here, PQ stands for previous question’s answer and 1234 is a question’s ID.
3.    Operand plug-in class-

•     Properties- e.g. QuestionID.
•       ReadOperand();  //  This function will get the value of the operand and store it in a variable having the same name as the operand string.
•       ConvertOperand(); //This function converts an operand class and its properties in string format.

The Conditions Manager (A vague idea)

It consists of following major functions:

   Conditions_storage()- This part will do the job of handling the GUI while storing conditions and actions into the three tables. Three possible functions:

•    Storeconditions() – The GUI gets a datatype as input which this function looks into the operands table to select the proper plug-in. It creates an object of that plug-in datatype. Activates functions in the plug-in to display context specific property in the GUI.User selects property in GUI which is stored in the object.The ConvertOPerand function turns the Object into string.All Operands after conversion are concatenated with the operator symbols and changed into RPN using the RPN converter.The strings are then stored into the conditions table with unique ID.
•    StoreActions()-It stores the actions in the action table depending upon input from the GUI.
•    Action_condition_connector() – This function connects the action and the conditions together.

   Conditions_ retriever()- This function will do the job of getting conditions from the condition table, action table and condition_action table and convert it into infix form.

   Conditions_trigger()-

•    This function is supposed to help in triggering a particular condition while running a survey.
•    We don’t want all conditions in a conditions table to be evaluated to check whether they are true everytime a new question is answered.
•    This function will scan the condition strings for keywords to pinpoint which conditions need to be evaluated.

   Conditions_implementer()-

•    This function will first use the conditions_trigger() to check which conditions need to be evaluated.
•    It will then get the conditions using function condition_retriever().
•    The evaluate function of the ExpressionEngine will then return a boolean value which will then be used to perform a particular action based on the ID of the particular action.
•    If the evaluate function returns a true then a function actions_retriever() is accessed which retrieves that action depending upon the ID in the condition_actions table.
•    Finally, the perform() function will tell the survey engine or jscript to perform  the particular action.