Forum OpenACS Development: ad_form -edit_request block not intuitive

I tried using the -edit_request block of ad_form and I was surprised that I couldn't just set a form variable and have the result show up in the initial presentation of the form. Searching through the code-base, I noticed that the survey package uses the ad_set_form_values proc to set the default values in the form from within the -edit_request block. This behavior is different from the other ad_form blocks which seem to have access to all of the form variables and the variables declared in ad_page_contract which are created at the template level. To make the behavior more regular, I modified ad_form so that form variables set in the -edit_request block are are set in the initial presentation of the form without requiring the user to call ad_set_form_values or ad_set_element_value. So instead of doing this (this assumes that "description" is a form paramter):

} -edit_request {

    set description "blah blah blah"
    ad_set_element_value -element description $description

}

a user could just do this:

} -edit_request {

    set description "blah blah blah"

}

This is more intuitive, and it will be less likely to trip up new users of ad_form.

The change involves a slight change to the -edit_request processing that copies parameter values from the template level to the __ad_form_values__ array which holds the current value of the form variables. The change is shown below (after the ad_page_contract_eval):

                ad_page_contract_eval uplevel #$level $edit_request
                foreach element_name $af_element_names($form_name) {
                    if { [llength $element_name] == 1 } {
                        if { [uplevel \#$level [list info exists $element_name]] } {
                            set values($element_name) [uplevel \#$level [list set $element_name]]
                        }
                    }
                }            

If nobody has a problem with this change. I will change ad_form and fix the affected code in the survey package.

Collapse
Posted by Jun Yamog on
Hi Dan,

I think that is better.  While you are at it can you also see if it still has the bug if "description" value starts with a dash "-".

set description "-blah blah blah"
ad_set_form_value description

Used to blow up because for some reason "-blah" is treated as a flag.  Thanks.

Collapse
Posted by Robert Locke on
Jun,

This is probably related to:

https://openacs.org/forums/message-view?message_id=67591

Try using a "--".

Collapse
Posted by Jun Yamog on
Hi Rob,

Thanks I believe that is the cause of it, I haven't tried yet though.  But according to the last post a FULL code sweep should be done for this?  I am going to change my code and update my Things 2 Remember.

Does this also happen on ad_proc that only make use of switches much like Yon has suggested and I have placed on my Things 2 Remember?

Collapse
Posted by Robert Locke on
Yes, if your "ad_proc"-defined proc encounters a "--" as it loops through its arguments, it assumes that every subsequent argument is no longer a "switch".  The native Tcl "proc" only supports arguments, the concept of a "switch" is an OACS add-on via "ad_proc".

I think the golden rule should be: if any of the arguments to your ad_proc could potentially contain a "-", then separate the switches from the arguments with a "--".