jQuery SheepIt demo indexes are wrong using nested forms

Question

I am using the demo here: http://www.mdelrosso.com/sheepit/index.php?lng=en_GB&sec=demo3

But if you have two of the outer forms (addresses) and two each for the inner forms (numbers) and inspect the elements you'll notice the names of the inputs still have the #index# and/or #index_phone# strings in the index names.

If you try to submit the form then, the field data is lost (since only the latest copy of that name is kept). I've tried debugging the JavaScript so I can patch it, but I'm not seeing where it's wrong. It seems like the normalizeForms function isn't handling nesting correctly.

What can I do to correct the code so the indexes perform as expected? (That is: so that an input of two addresses (A and B), each with two phone numbers (A1, A2 and B1, B2) gives me a POSTed value like:

"people" : [
   0 : {
       "addresses" : "A",
       "phones" [ 0 : "A1", 1: "A2" ]
   },
   1 : {
       "addresses" : "B",
       "phones" [ 0 : "B1", 1: "B2" ]
   }
]

(Note: I'm not looking for that exact format; I can parse any output, I just need to get all of the data from the client to the server with meaningful indexes and without conflicts.)

score 1 · Accepted Answer · answered Jun 09 '18 at 14:44

There appear to be some fundamental logic issues with the index 'normalization' side of this plugin when it comes to the nested inputs.

Essentially there is is a nametemplate and an idtemplate which are the element names only with %index% or %index_phones% where the index should be, and then the name and id which should be these templates only with the %index% or %index_phones% replaced with the actual element input ids.

What happens during the 'normalization' process is that a function runs over these templates (once per element per form), and depending on the form, replaces either %index% or %index_phones% with the relevant index, depending on which form is being processed.

The problem arises when the inputs are nested, as the function first replaces (for instance) %index% with let's say 0. It then updates the resulting name or id with this value, say person_addresses_0_phones_%index_phones%_phone. When it hits the nested form, it then does the same again, only with %index_phones%. The result is now person_addresses_%index%_phones_0_phone because it is still using the unmodified template attribute, rather than the already half-modified name.

To fix this properly, the logic around this whole section of the plugin really needs rebuilding, but I have slapped together a quick patch which should serve as a temporary fix.

In the main plugin file, update the normalizeFieldsForForm function to be:

    function normalizeFieldsForForm(form, index)
    {
        form.find(formFields).each(function(){
            var that = $(this)
                ,idTemplateAttr = getOrSetTemplate(that,"id")
                ,nameTemplateAttr = getOrSetTemplate(that, "name")
                ,idAttr = that.attr("id")
                ,nameAttr = that.attr("name")
                ,formParents = that.parents('[idtemplate]')

            /* Normalize field name attributes */
            var newNameAttr = nameTemplateAttr.replace(options.indexFormat, index);

            /* Normalize field id attributes */
            var newIdAttr = idTemplateAttr.replace(options.indexFormat, index);

            $.each(formParents,function(index,element){
                $element = $(element);
                if($element.data('indexFormat') != options.indexFormat){
                    /* Normalize field name attributes */
                    newNameAttr = newNameAttr.replace($element.data('indexFormat'), $element.data('formIndex'))

                    /* Normalize field id attributes */
                    newIdAttr = newIdAttr.replace($element.data('indexFormat'), $element.data('formIndex'))
                }
            });

            form.find("label[for='"+idAttr+"']").each(function(){
                $(this).attr("for", newIdAttr);
            });

            that.attr("id", newIdAttr);
            that.attr("name", newNameAttr);
        });
    }

And then update the addForm function. Around line 385 in an unmodified plugin file, add the line

    // Index format
    newForm.data('indexFormat', options.indexFormat);

above the line

    // Index
    newForm.data('formIndex', getIndex());

This should serve as a fix until the plugin author gets around to fixing the logic issues. This is for plugin version 1.1.1

jQuery SheepIt demo indexes are wrong using nested forms

1 Answers1

Linked