Forum OpenACS Q&A: ad_form oddity with validation

Collapse
Posted by Chris Davies on
I have a form that had a field with a type of URL, but it accepted asdf as a valid url.  Obviously, that's not totally coorrect, but, could be based on some particular settings.

set expr {^(https?://)?([a-zA-Z0-9_\-\.]+(:[0-9]+)?)?[a-zA-Z0-9_.%/?=&-]+$}

That regexp is rather strange because there are some valid URLs that seemingly could be constructed, that would not pass that regexp.  Likewise, there are some invalid urls that can obviously pass the regexp.

My temporary solution to this is to move the validation into its own block in my process, but led me to check a few other things.

I had a form that I specified to test URL and all of the other element types, and came up with some strange results for Boolean and URL.

ad_page_contract {
} {
    note_id:integer,optional
}

ad_form -name addresource -form {
    {resource:boolean
        {label "URL of Link"}
        {html {size 60}}
    }
} -after_submit {
ad_returnredirect "test"
}

The above form when fed    asdf    as the resource, accepts the resource as being a valid boolean.  This in itself seemed to be something strange in the validation, because no matter what I sent, it always came back as valid.  Some investigation resulted in finding the one line that seems to fail:

ns_log Warning "1>" $value "<"
  set value2 [string tolower $value]
ns_log Warning "2>" $value "<"
ns_log Warning "2>" $value2 "<"
ns_log Warning [string tolower asdf]

results in

[06/Dec/2003:01:08:02][7723.1093049584][-conn:daviesinc.com::2] Warning: 1> asdf <
[06/Dec/2003:01:08:02][7723.1093049584][-conn:daviesinc.com::2] Warning: 2> asdf <
[06/Dec/2003:01:08:02][7723.1093049584][-conn:daviesinc.com::2] Warning: 2> 1 <
[06/Dec/2003:01:08:02][7723.1093049584][-conn:daviesinc.com::2] Warning: 1

Obviously, string tolower asdf is altering the value of value2 in this case to 1 rather than asdf.  So, pulling that code and running it through tcl 8.3 or 8.4, results in code that works perfectly.

What is it that would cause AOLServer with OpenACS 5.0 beta to cause tolower to return 1 rather than asdf?  both versions of TCL that I have running on my laptop always work properly.

Running Debian SID, AOLServer 4.0 Beta 10, OpenACS 5.0 beta tarball

ii  tcl8.3                          8.3.5-4                        Tcl (the Tool Command Language) v8.3 - run-time files
ii  tcl8.4                          8.4.4-1                        Tcl (the Tool Command Language) v8.4 - run-time files

It doesn't appear to be a bug in OpenACS, because the code when pulled out and put in its own script works as expected.  Any thoughts or hints would be greatly appreciated.