Home
The Toolkit for Online Communities
17614 Community Members, 0 members online, 2935 visitors today
Log In Register
OpenACS Home : Forums : OpenACS Development : Possible bug in ad_form

Forum OpenACS Development: Possible bug in ad_form

Icon of envelope Request notifications

Collapse
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:
    {trigger_type:text(radio)
        {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.

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

Collapse
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?
Collapse
Posted by Jarkko Laine on
Don,

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.

Malte,

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.

Collapse
Posted by Jarkko Laine on
OK, I filed this here: http://openacs.org/bugtracker/openacs/bug?bug%5fnumber=2163

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