Overview

The  As_Item and Section catalogues are central parts of the assessment system. These repositories support reuse of Assessment components by storing of the various as_items (or questions if you like) and groups of as_items (e.g. Sections) that can be used in an assessment. You are able to add/edit/delete an as_item of a certain type to a certain scope. Furthermore it allows you to search and browse for questions for inclusion in your assesment as well as import and export multiple questions using various formats.

In this description here we will only discuss the design implications for as_items. Green colored tables have to be internationlized.

Each as_item consists of a specific as_item Type like "Multiple Choice Question" or "Free Text". Each as_item Type adds additional Attributes to the as_item, thereby making it pretty flexible. Additionally each as_item has a related display type storing information on how to display this as_item. This way we can create an adp-snippet which we can include to display a certain as_item (the snippet is stored de-normalized in the as_items table and update on every change to the as_item or the as_item_type).

How is this achieved concretely? Each as_item Type has it's own table with attributes useful for this as_item type. All tables (as_items, as_item_type_*, as_item_display_*) are controlled by the content repository. Each as_item is linked using acs-relationships to the specific items of the as_item_type_*  and as_item_display_* tables. Each as_item can only be linked to one as_item_type instance and one as_item_display instance.

Categorization and internationalization will make it into OpenACS 5.2, therefore we are not dealing with it in Assessment seperately but use the (to be) built in functionality of OpenACS 5.2

Additionally we have support functionality for an as_item. This includes the help functionality. To give Assessment authors flexibility in adapting as_item defaults, help messages, etc for use in different Assessments, we abstract out a number of attributes from as_items into mapping tables where "override" values for these attributes can optionally be set by authors. If they choose not to set overrides, then the values originally created in the as_item supercede.

Seperately we will deal with Checks on as_items. These will allow us to make checks on the input (is the value given by the user actually a valid value??), branches (if we display this as_item, which responses have to have been given) and post-input checks (how many points does this answer give).

Here is the graphical schema for the as_item-related subsystems, including the as_item Display subsystem described here.

Data modell graphic

Core Function: as_items

As_item Types

as_item Types (as_item_type_*) define types of as_items like "Open Question", "Calculation" and others. The as_item type will also define in what format the answer should be stored. For each as_item type a cr_as_item_type will be generated. Each object of this type is linked to the primary object of the as_item (see above) using relationships. This has the benefit that we split the core attributes of an as_item from the type specific ones and the display ones (see down below). Using cr_as_item_type usage allows us to create and reuse standard as_items (e.g. for the likert scale), by linking different questions with the answer possibilities (and the same attributes) to one as_item_type object. If we have objects that are linked this way, we can generate the matrix for them easily. A functional list of all as_item types and their attributes can be found in the requirements section.

Item Display Types

Each item has an item_display_type object associated with it, that defines how to display the item. Each item_display_type has a couple of attributes, that can be passed to the formbuilder for the creation of the widget. Each widget has at least one item_display_type associated with it. In the long run I think this system has the potential to become a part of OpenACS itself (storing additional display information for each acs_object), but we are not there yet :). Obviously we are talking cr_item_types here as well.

Each item_display_type has a couple of attributes in common.

Depending on the presentation_types additonal attributes (presentation_type attributes) come into play (are added as attributes to the CR item type) (mark: this is not feature complete. It really is up to the coder to decide what attributes each widget should have, down here are only *suggestions*). Additionally we're not mentioning all HTML possibilities associated with each type (e.g. a textarea has width and heigth..) as these can be parsed in via the html_display_options.

Help System

The help system should allow a small "?" appear next to an object's title that has a help text identified with it. Help texts are to be displayed in the nice bar that Lars created for OpenACS in the header. Each object can have multiple help texts associated with it (which will be displayed in sort order with each hit to the "?".) and we can reuse the help text, making this an n:m relationship (using cr_rels). E.g. you might want to have a default help text for certain cr_as_item_types, that's why I was thinking about reuse...

Relationship attributes:

Messages (as_messages) abstracts out help messages (and other types of messages) for use in this package. Attributes include: