Question object types

Question object types is about making questions in LS more object-oriented and modular, and letting users create and upload their own object types.

Basically, every place in the code which is doing a switch on question type should be replaced by a polymorphic call to an object, e.g. $object->renderFrontend();

Use-cases

• Colour picker - user click on a picture with colours, and the position in the picture defines the colour.
• "... the surgeon would indicate the location of a fracture by drawing on a diagram of the knee."

Features

TODO

Open issues

• Is array it's own object type, or is it a property of a question? Could we have an array of any question typ, e.g. yes/no questions?
• Cross-cutting concerns: What if the user wants to add a comment field to all questions in the survey? Or timing?
• Composability: Should it be possible to combine two questions into one, or pick-and-choose among "question elements"?

Implementation

Object hierarchy.

Minimum requirements

This is a list of functions that all question types must implement. They should be included in a "base interface" or base class.

If not implemented they could throw an NotImplementedException (must be catched higher up).

Function name	Meaning
renderFrontend	Former qanda code; render question for survey taker
renderEditForm	Render the backend edit form
renderPDFStatistics	Render question statistics for PDF format
renderHTMLStatistics	Render question statistics for HTML (back-end statistics view)
renderXLSStatistics	Render question statistics for XLS

Implemented as Yii module, with views, models and controllers (http://www.yiiframework.com/doc/guide/1.1/en/basics.module#creating-module).

Replace switch-cases in:

• Frontend render (render answers, qanda)
• Backend render (edit question settings)
• Statistics
• SQL and database queries, included extra field the question might define
• Expression manager

Ideally, each switch case in the code should have a unit test or functional test to test it with.

Prototype/proof-of-concept

As a first cycle of development (iteration), one could implement a completely new question type (say, drawing board) with the new system on top of the old one. The purpose would be to get a better feeling of the problem domain, what changes are needed, if the current approach is possible, and so on.

After the prototype is done, the existent questions can be exported to the new system one by one. This represents a "horizontal" development style, where the complete problem is solved for _one_ case in the first cycle, in contrast to exporting the entire qanda to the new system, then the entire statistics module, etc. A horizontal style would give faster results and introduce lesser mechanical work, focusing on design and creativity which is needed in the beginning.

Example from qanda:

if (is_object($ia))
{
  $ia->renderFrontend();
}
else
{
    switch ($ia[4])  // $ia[4] is question type
    {
        case 'X': //BOILERPLATE QUESTION
            $values = do_boilerplate($ia);
            break;
        // and so on for all question types
    }
}

Current LS3 implementation

Note, this is the current state and some of these are mostly because it is a refactoring from LS2.

1. Uses an interface.

2. Defines what columns it needs via a fieldname => column type map.

3. Defines what EM expressions apply to it.

4. Defines a render functionality that renders the content.

5. Defines a list of classes that should be in the wrapping div.