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.

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 converting 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.

Operands

The basics

Each operand plug-in will have a class contained in a file. Data on conversion of a particular operand code to human readable text will be stored  in the operand table. Possible fields : Operand_code, Operand_text.

Example class:

class PQ_plugin

{

   QuestionID;

   Other keywords;

   convertoperand(); //returns the coded name of the object(from the operand table)

   getoperand(); //gets all the keywords and there representations to be used in the form in the GUI

   readoperandval(); // uses getoperand() to get keywords and contains statements to access the value

}

Each function is specific to an operand, so all keyword handling is abstracted from the conditions manager's eyes. All that is the operand plug-in's work.

Grammar for operand storage

An example of the representation of an operand is FUQT_1234. This implies the FUQT class and file number 1234. We don't need to explicitly define in the operand string what a particular keyword points to. All this will be done by the getoperand function of a particular plug-in class depending upon the keywords defined in the class. Each plug-in will have its own set of keywords, and getoperand, readoperandval and convertoperand functions. Each plug-in's functions will define exactly how to perform the task implied by the function's name with respect to that type of operand.All the routing work of giving the task of reading, converting to the plug-in will be done by the conditions_manager which will try to find a class of similar name as the datatype or some modification of it in a fixed directory.

Operand role in conditions_storage() :

On getting input through the GUI, the conditions manager looks up the operand table and tries to find a class of similar name and create its object. The getoperand() function then comes into action and provides the GUI with data on what type of form elements need to be dynamically created for the keywords input(like selecting what keyword related to that operand is to be used in the condition). After all necessary objects are created, the convertoperand() function converts the operand into code form using operand table.

Operand role in conditions_retriever() :

It will use getoperand() function  to get the operand data (like keywords) and also use the operand table to display the operand in text form wherever necessary.

Operand role in conditions_implementer() :

Uses readoperandval()which in turn uses getoperand to get data on keywords. It(readoperandval() has functions and statements to gain access to the value of the operand.

Excerpts from DBSE-CE meeting 6/7/2010

1. Conditions and Actions will remain independent objects.

2. Actions will use the same Expression Engine

3. DBSE will provide observer to let us know when to trigger conditions/Actions

4. A new possible table-layout of 3 tables : conditions-actions, bindings, and conditions-actions mappings

5. An example of condition : {var} getanswer 'filesize' geattribute 1000000 <

6. {var} is accessed through bindings table i.e all necessary data like(survey_id, question_id) stored in bindings table.