Forum OpenACS Development: Possible bug in ad_form

Request notifications

Posted by Jarkko Laine on
I'm not sure if this is a feature or a bug in ad_form/form builder but I thought it's still good to know since tracking it down gave me a major headache. I have this kind of element in ad_form:
        {label {[ad_decode $num_sub_actions 0 "Trigger Type" "Trigger Type<br>(Cannot edit because
task has child tasks)"]}} {mode {[ad_decode $num_sub_actions 0 "" "display"]}} {options { { "User task" user } { "Automatic timer" time } { "Initial action" init } { "Workflow" workflow } { "Parallel" parallel } }} {html {onChange "javascript:acs_FormRefresh('task');"}} }

Now when this element is in display mode, all the options are grayed out and the current one (here "Workflow") is checked, just like it should. However, when submitted, $trigger_type is an empty string. Not "workflow" as expected. Nada.

I don't know if this behaviour is intended or not, but it was a major surprise for me. The problem is that applications usually trust that the field has a real value (it's a required field, after all) and when it's now set to empty string, they overwrite the current (and correct) value with that.

I catch this in simulation so that when the mode is update (this can't happen in insert mode, since trigger_type is a required field), I check for empty string in trigger_type and unset it if that's the case. However, I would feel more comfortable if ad_form would set the value correctly even if it's in the display mode.

Posted by Don Baccus on
Well, I grumbled when the collaboraid folk overloaded ad_form with this display functionality, which wasn't part of the original design at all.

This is definitely a bug.  I've not looked at the code that was added to handle display mode, do you have time to track it down?  ad_form has become a complex mess internally at this point.

Posted by Malte Sussdorff on
  • How often is the display mode used by people. What is the alternative?
  • Is it to late to switch and unload the display functionality from ad_form?
  • What is the alternative?
  • Does it have profound implications on performance (to have it all in one place)?
  • Is the major obstacle "just" the diffculty to maintain the beast?
Posted by Jarkko Laine on

I'm in Leiden this week to make simulation fit for production. I'll see if I have the time to track this down. Anyway, I'm gonna file this right now.


Simulation uses the display mode extensively. But then, it's Lars' product, just like the display mode. I think the alternative at this point is to write your own code for viewing an item (or parts of it), or write a general application for it. I don't know, tho, how a case like this (an element inside a form, that actually uses form widgets that are just disabled) could be easily solved without ad_form having the functionality.

About the performance: I doubt that it has any significant effects on performance, but this is just my hunch, it's not based on any real facts.

Posted by Jarkko Laine on
OK, I filed this here:

I also found the cause of the bug with the help of Alfred and Dave. See the bug tracker entry for more info.