While working on the assessment system I realized that the whole generation of sections is nothing else but creation of forms. Therefore I think it is best to add the functionality we need for the assessment system into the templating and ad_form directly instead of doing things only for assessment (as it is done now for survey). Therefore I thought about some extensions to ad_form. In spirit with Don's latest comments, I'm not utterly sure if ad_form already supports some of this in different ways.
First I will look into attributes we would have to add to ad_form as switches to allow the assessment system to build forms easily afterwards. This should give you a rough picture what we need. Skip the next paragraphs if you are "only" interested in the design changes and not the why :).
For ad_form we have to differentiate between display options for the whole form and for each element. Let's first look at the display options for the whole form:
* pagination_style - all-elements on one page; one-element-per-page; variable.
* element_orientation - the pattern by which 2..n Elements are laid out when displayed. Note that this isn't a purely stylistic issue better left to the .adp templates or css; the patterns have semantic implications that the author appropriately should control here.
1. horizontal - all Items are in one line
2. vertical - all Items are in one column
3. matrix_col-row - Items are laid out in matrix, filling first col then
row
4. matrix_row-col -Items are laid out in matrix, filling first row then
col
* element_labels_as_headers_p - whether to display labels of the Elements; if not, a "grid of radiobuttons" gets displayed. See discussion of Items and Item Choices here. There are contexts where a Form of Elements all share the
same Choices and should be laid out with the Elements' subtexts as row headers and the radiobuttons (or checkboxes) only -- without their labels -- displayed in a grid (see this example).
* element_alignment - the orientation between the "section description part" of the Form (if any) and the group of Elements. Alternatives accommodate L->R and R->L alphabets (or is this handled automagically be Internationalization?) and include:
1. beside_left - the Elements are left of the "heading"
2. beside_right - the Elements are right of the "heading"
3. below - the Elements are below the "heading"
4. above - the Elements are above the "heading"
---
As for item attributes, I just endulge myself and copy paste from the as_item_specifications. Please replace Item with Element and Section with Form ;).
* choice_orientation - the pattern by which 2..n Item Choices are laid out when displayed. Note that this isn't a purely stylistic issue better left to the .adp templates or css; the patterns have semantic implications that the Assessment author appropriately should control here. Note also that Items with no Choices (eg a simple textbox Item) has no choice_orientation, but handles the location of that textbox relative to the Item label by the item_alignment option (discussed below).
1. horizontal - all Choices are in one line
2. vertical - all Choices are in one column
3. matrix_col-row - Choices are laid out in matrix, filling first col
then row
4. matrix_row-col -Choices are laid out in matrix, filling first row then
col
* item_choice_alignment - the orientation between the "question part" of the Item (the item_text/item_subtext) and the "answer part" -- the native Item widget (eg the textbox) or the 1..n choices. Alternatives accommodate L->R and R->L alphabets (or is this handled automagically be Internationalization?) and include:
1. beside_left - the "answers" are left of the "question"
2. beside_right - the "answers" are right of the "question"
3. below - the "answers" are below the "question"
4. above - the "answers" are above the "question"
Additional ad_form element types:
* pop-up_date - a widget with month-day-year select elements that resets the day element based on year and month (ie include Feb 29 during leap years -- via Javascript) and tests for valid dates
* image_map - requires a linked image; the image map coordinates are handled as Choices
As we have to write a dynamic interface anyway, this interface could be reuseable for the dynamic generation of templates for use in ad_form (which in return could be reused to change the style of forms across the whole system). This could in the end lead to a dynamic checking and displaying system for ad_form.
Here is my idea on this:
- A style is a name for a certain set of attributes which we would otherwise have to pass on manually to ad_form.
- Changing styles over the web interface will allow quick an easy change of the look and feel of forms.
- Styles will be bound to the form_name and the package_id. For obvious reasons there has to be a unique constraint on this combination.
- Styles will be stored in the database. We will cache the form's adp-like content and flush it on each change to either a used form element (and style) or form_style. As mentioned above, the cache should store the form_name and the package_id. The assumption here is that we are not going to see a change of styles very often in a production environment, neither a change of styles.
- In a future version (not needed by assessment), it would be nice if the templating system would allow the overwriting of styles defined in the code with styles assigned to pages through the web interface. Take the translator mode as the general idea. If you see a form, you can change the style of the form for this form_name & package_id, by clicking on a link "change form style" and select one of the predefined ones.
Now, more specifically:
- You create form styles (with the attributes described above and those already in ad_form). Alternatively you can directly manipulate the adp-like content of the form and store this as a template. In this case the cache will obviously not be flushed if the elements or form_style change but only if the template changes (or it is deleted). You can call ad_form with an option switch form_style that would make use of this dynamic method. See assessment sections for this idea.
- You have multiple form element display styles. Some are predefined as they are now in the code, others could be added dynamically using a description "language" or parameters as described above. See as_item_display types.
Examples of styles would be "Select box, aligned right" or "Radio buttons, top down, left oriented".
- You have multiple form data entry check elements. These will be the validation part of ad_form. Some could be predefined, e.g. "not null", "integer", "date" while others should be handled on a case by case basis (e.g.: where element labeled "nickname" has to be "not null" if element
labeled "about me" is "not null").
I'm not entirely sure, if we should go further and also include the branching / sectioning functionality of the assessment system into the form templating system itself. I doubt it's usefulness for normal forms, but who knows ....
Let me stress again, this is a proposal for discussion especially in Heidelberg as we need to make extensions to form templating for the assessment anyway. But an assessment's core is nothing but a form with additional display options. Therefore the idea is to enhance the existing functionality and make use of this by the assessment system instead of just adding this functionality to the assessment system on it's own. If the majority feels ad_form and the like is already cluttered with too much functionality and assessment should keep it's stuff to itself, this is as good an answer as anything else.
If people lean towards extending form templating in a way as described above I will write up a formal RFC copy / pasting from the assessment design specs and re-label items and sections to form elements and forms for your convenience.
