[pmwiki-users] WikiForm variable names (was: wikilist searching) (Peter & Melodye Bowers)

[John Rankin]

On Thursday, 25 October 2007 7:49 PM, Peter & Melodye Bowers <pbowers at pobox.com> wrote:
>(1) Variable names need a little more flexibility.  I had already noticed
>(and put in a feature request on the wiki) that underscores in a variable
>name cause that field to be ignored.  Now the problem with uppercase shows
>in the selection.  An intentional definition of the syntax of a variable
>name should be made and then applied throughout.  "[A-Za-z_][A-Za-z0-9_]*"
>is pretty standard in other languages although I'm not familiar with php...
>(Hyphens might be nice too?)
>
I have looked into this and discovered some questions and areas where some
requirements advice would be helpful. In summary: proceed with caution;
changing this may have unexpected side-effects. Let's recap how wikiform 
variables work.

(longish post coming up)

Suppose we have a field defined like this:

:Some field:fieldname Tool-tip instructions (fieldtype)

The relevant php code to decode the lines and assign values to the
form control elements is (note the 2 [:alnum:] occurrences):

    foreach(explode("\n",@$formpage['text']) as $x) {
        if (preg_match("/^:+([^:]+?):(\\*)?([[:alnum:]]*?)(?:\\s+([^-+\\(]+?))?(?:\\s*\\(([^\\)]*?)\\))?(?:\\s*([-+]\\*?)?)(?:\\s+(\\d[-+]))?$/",
            $x,$match)) {
            $f[$n]['eprompt'] = $match[1];
            $f[$n]['element'] = ($match[3]) ? $match[3] : 
                preg_replace('/[^[:alnum:]]/','',strtolower($match[1]));
            if ($match[2]=='*')
                SDV($FormTitleFmt['csum'], $f[$n]['element']);
            $f[$n]['etitle']  = 
                str_replace(array('"',"'"),array('&#34;','&#39;'),$match[4]);
            $f[$n]['etype']   = $match[5];
            $f[$n]['elist']   = $match[6];
            $f[$n]['esum']    = $match[7];
            $n++;
        } ...
    }

In practice, this means a form administrator can write

:A Field:

and wikiforms will work, generating a fieldname called afield

So will this:

:A Field:(text)

This will also work

:A Field: Please enter a value for this field

generating a fieldname called afield and tool-tip of "Please..."

This works too:

:A Field:* Please enter a value

This does not:

:A Field:Please enter a value

So, if we allow fieldnames to start with an upper case letter,
the above example will generate a fieldname called Please and
a tool-tip of "enter...". If there is another field like

:Another One:Please enter another value

we end up with 2 fieldnames called Please, the sky will 
fall and there will be tears before bed-time.

A lot of the time, I don't bother specifying fieldnames,
but let wikiforms generate them for me. I also thought 
it would be a good idea not to let fieldnames take the 
form of WikiWords (even though these are now disabled).

The conclusion I reached is that "simpler is safer". Even
allowing an underscore is slightly problematic. What does
the code do with

:A       Field: Please enter a value

Is the variable name afield, a_field or a______field?

I think the code could be made to cope with names of the
form [[:alnum:]][[:alnum:][:upper:]]* and the example
above would generate aField as the fieldname. However,
in that case, what do we do with:

:A field: Please enter a value

Is the fieldname afield or aField? Should this
produce a different fieldname:

:A Field: Please enter a value

All the answers seemed to me to include a degree of 
arbitrariness and I concluded that the safest, least 
ambiguous pattern was [[:alnum:]]. From a user point 
of view, "fieldnames must be all lower case" is very 
easy to understand and remember.

The trade-off is between *either* allowing wikiforms to
generate a fieldname if none is supplied *or* allowing
more flexible fieldnames. Making the *or* into *and*
appears to be much work for little benefit and perhaps
more confusion. I wonder if "flexible fieldnames" falls
into the "gratuitous feature" category -- when in doubt,
leave it out.

I hope this (rather long) post clarifies the issues.
The post lays out the thinking behind the decision,
but I am always open to counter-arguments.
-- 
JR
--
John Rankin