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
• EM

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

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.