fields in EditTemplate saved with case-sensitive field names

[EricShulman]

Fieldnames are supposed to be case insensitive, so you can use either "FooBar?" OR "foobar" as the field name. This is enforced by the core functions for accessing custom fields: store.getValue() and store.setValue(), which automatically apply toLowerCase() to the field name before processing.

However, when editing a tiddler using an EditTemplate?, the 'done' command handler uses it's own code, gatherSaveFields(), to assemble an array of fields which it stores, en-masse, in the tiddler... without case-folding the field names first.

As a result, if you use <span macro='edit FooBar?'></span> in the EditTemplate?, it will create a custom field called "FooBar?"... which store.getValue() and store.setValue() cannot access (because they *always* case-fold the fieldname and will look for "foobar", not "FooBar?")

This problem can corrected by case-folding the fieldnames in gatherSaveFields(), by changing this line:

fields[f] = e.value.replace(/\r/mg,"");

to

fields[f.toLowerCase()] = e.value.replace(/\r/mg,"");

[EricShulman]

Note: this ticket is still open because the above suggested fix is NOT sufficient. Unfortunately, there are other places in the core that also access custom fields without using getValue()/setValue().

Until this can be resolved (if at all), the *workaround* is to USE ONLY LOWER-CASE for custom fields names.

[cdent]

Is case insensitivity still desired? in external storage systems, like TiddlyWeb, as much as possible things (including fields) are case sensitive.