Forum OpenACS Q&A: Dynamic attribute generation and other assessment related questions.

For the assessment system we are dealing with items (think questions). Each item is of a certain display_type, question_type and has a not predefined number of validation checks. Each display and question_type have different attributes associated to them. It is unclear how to best deal with a situation like this in OpenACS.

Currently we want to implement it this way for display_types:

• All items (questions) are cr_items with a display_type attribute.
• Each items is of a certain display type (e.g. string, textarea, date, multiple_other, matrix).
• Each display type has a corresponding widget in the form builder.
• Each display type might have additional attributes (e.g. minimum, max. for Likert scale, width for string, display_style for date). These attributes will be stored as XML in the "additional_display_attributes_xml" attribute of the item.
• When an item is displayed, the form builder is called with the XML split up into switches.

Now I got a few questions:

1. Is the use of XML in that way supported or is a different way prefered (we have one cr_item_type that can have multiple different attributes, depending on one attribute). I could think of having a seperate as_items_attributes table, that stores additional attributes for the items.
2. Is it okay to extend the form builder calls by switches we think are necessary for assessment (can we bunch TIP them?).
3. As each question type (e.g. multiple choice, multiple other, date aso.) has different attributes, is it safe to assume that we need to create different cr_item_types?
4. Would choices for a multiple choice question be childs of the item? Taking into account that we are dealing with different types, should we create a multiple_choice relationship between the item and it's choices (yes, choices are going to be cr_items as well).
5. Is it possible to create n:m relationships with the current cr relationship model (I assume yes, just want to confirm). The same choices might be assigned to multiple items.
6. ad_form has the nice validation block. Shall we feed this the tcl code generated by the as_item_checks (each item can be checked on input for valid input, depending on the type of check (range, distinct_values, length) and it's attributes) or is there a different way.
7. When can the TCL API be expected for dealing with the CR? Is it possible to use already some functions? Is help/funding need to get this out of the door (fast) ?
8. Will the TCL API deal with internationalization of content (see Joel's posting) and if yes, how (I think this asks again for the API 😊)
9. How will version inheritance work with cr_rels? If I change a choice for an item in a section of a survey, will the survey (and all steps in between) get a new version? Will I be able to easily retrieve a cr_item by it's version at a certain time? Will it be possible to retrieve all childs with an cr_item as well in one go (e.g. getting the cr_item for one question and retrieving the related choices with one call)? See https://openacs.org/projects/openacs/packages/assessment/design/versioning for a clue where these questios come from.
10. As the assessment is not much different in the question handling part than the new object oriented approach of ACS 6 (t.b.d.), what is the thinking there, how does it interact with the stuff mentioned above, timeline? It would be aweful if we are to write things in a certain way for assessment just to realize, hey, OpenACS changed the way it is handling objects and therefore all we did is not in line with OpenACS anymore.
11. What is the current thinking with regards to xhtml/css. What can we as package developers do *NOW* to make our package comply with the thinking in that direction for the 5.2 release ?

Thanks a lot for taking the time to answer these questions, some might be obvious, please accept my apologies, but I got a little bit confused about the many things happening at the same time, pulling (client driven) in multiple directions and much of this affects the way we want to write assessment (basicly get it right this time).

Malte,

Overall you can see that assessment is a dynamic form generation system itself.

The object level form generation code would work from an object type definition. AFAICT to make the assessment form generation work similarly, each question or possibly each survey would be an object type. So I don't think it is really possible to make them coincide.

I would not recommend putting XML into a database column to store attributes. The only way that might be wise is if you were using a standard XML format for assessments.

Besides all that, I want to recommend that you pre-generate the adp templates that will contain the forms for each survey. I don't think there is any efficient way to build a form with each question and choice stored in a different content item.

Malte,

I agree, each question should not be an object type. But to use the object_type attributes to define questions, it would have to be. So I think you already will need to build your own system for form generation.