Forum OpenACS Development: Extending ad_form for assessment ?

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
  4. matrix_row-col -Items are laid out in matrix, filling first row then

*  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

*  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.

Posted by Jeff Davis on
I certainly would like some way to present radio buttons and checkboxes on one line or in a matrix but it should not be ad_form specific; I think its best to approach changes like this via the templating api and then think about how to expose that via ad_form.

I don't think branching belongs in ad_form...

Posted by Dave Bauer on
I don't think any of this has to do with ad_form, as Jeff says. Any enhancements belong in the form builder.

To arrange items I was thiniking of a simple grouping idea. So you would just define a group id for form elements, and all items with certain group_id would appear together.

I think the "stlyes" you are talking about are form templates. I don't see any reason to do this another way, we already have a built in way to address styling of forms through the form template feature.

We need to take this up with the object attribute system, and the effort to normalize the object attribute/ad_page_contract/form builder attributes and validation.

So anything that is added to form builder should be first to support the definiton of attributes for objects and their relation to form elements, and then the assessment could take advantage of that, even though an assessment question won't be an object type.

Posted by Malte Sussdorff on
I realized after talking to Dave and Jeff on IRC that we should, if at all, extend the form builder, not ad_form.
Posted by Bart Teeuwisse on

I applaude that decission. Ad_form started out as a convenience hack on top of form builder. My impression is that is being overloaded with too many bells and whistles. Last time I tried ad_form I immediately ran into usability issues.

So kudos for fixing the form builder. The strength of OpenACS is in the modular architecture and not in all encompassing APIs like ad_form.

My 2 cents.


Posted by Don Baccus on
Well, I think it's obvious I agree with Bart :)  I didn't mean to give birth to a five-headed monster, really!

Yes, the grouping issue is one that's bugged me and we should adress it.  Currently you can do with by writing a custom style that groups every instance in your form on one line (I did that for GP) but of course that's just as wrong, just in the other direction.

I would like to see as much of the other issues as possible solved via new form builder datatypes and widgets.  You can do a surprising amount of relatively complex things this way.  For instance I built things like a multi image datatype and widget for Greenpeace (used to input images for a slideshow).

Next in desirability IMO is new modes for the form builder, with ad_form wrapping it to expose the functionality.

Bottom in desirability is writing a brand new form builder :)

Posted by Andrei Popov on
Wouldn't it (or some of it) be possible if instead of tables a DIV'ed (with proper classes and ids) form template were used?  At least some horizontal vs. vertical and possibly some of the groupings could be resolved.

Otherwise -- that'd be grate, since in it's current form it's usable for quick-and-dirty things, but would never produce a shiny (and very usable) ones.

Posted by Juanjo Ruiz on
Hi Andrei,

I've read in the TIP #8 proposal that you have a DIV'ed version of the ad_form template.

Could you contribute that to the community? I've just started to use DIV instead of TABLE and it would be great to have such a template.

Thanks in advance,

juanjo \o.o/