Forum OpenACS Development: 'Bug' fix in element-procs.tcl

Collapse
Posted by Lee Denison on

I noticed a bug in element procs:

ad_proc -private template::element::copy_value_to_values_if_defined {} {
    define values from value, if the latter is more defined
} {
  upvar opts opts
  # values is always defined, init to "" from template::element::defaults
  if { [info exists opts(value)] && [llength $opts(values)] == 0 } {
    if { [string equal opts(value) {}] } {
      set opts(values) [list]
    } else {
      set opts(values) [list $opts(value)]
    }
  }
}

Clearly it should be [string equal $opts(value) {}] (with the $) but 'fixing' this causes problems elsewhere. ad_form for example, doesn't declare variables that it exports as optional but when empty string is exported explicitly (as in acs-subsite/lib/user-new) ad_form would explode without the unintentional behaviour above. I didn't want to commit a fix to the code above when there are issues that people may not be aware of.

Collapse
Posted by Lee Denison on
As a footnote to this - I have fixed this bug and updated ad_form to make exported values optional and it appears to work on my local server. That's no guarantee, however, that there are no other places in the code that depend on the old behaviour.
Collapse
Posted by Lee Denison on
Whilst I'm on the subject. Does anyone know if there is a reason why the forms api refuses to distinguish between a value not being supplied and it being explicitly empty string? It seems right that the -optional flag should cause a validation error in either case but I would have thought it would be useful if other code can tell the difference. The forms api seems to want to make them appear the same.