Custom fieldtype with extended control notation fails

[idbr]

There seems to be a problem when defining a custom fieldtype that contains an element with extended control definition notation. When two fields use this fieldtype, the following error is thrown:

uncaught exception: [ConstructorRegistry.get] No registered constructor found: composite in registry ConstructorRegistry: Registry of [Form] controlTypes

To reproduce the problem, use this form config:

var fconf = {
  "createURI": "${publicUri('service:/data/contact/')}",
  fieldTypes: {
    'mycompositefieldtype': {
      base: 'string',
      control: {base: 'input-control'}
    }
  },
  type: {
    members: {
      'instance1': {
        base: 'mycompositefieldtype'
      },
      'instance2': {
        base: 'mycompositefieldtype'
      }
    }
  }
};

When only instantiating one field,...

  ...
    members: {
      'instance1': {
        base: 'mycompositefieldtype'
      }
    }
  ...

... no error is thrown, so the fieldtype is defined ok.
Also, when changing the control definition of the custom fieldtype to the short notation, it works, even with two instances.

  ...
    fieldTypes: {
      'mycompositefieldtype': {
        base: 'string',
        control: 'input-control'
      }
    },
  ...

On further investigation, it seems that the in-memory fieldtype object is changed when creating the first instance, more specifically, the control variable first points to a js object with a member base, but afterwards it's an object of type Control.

This is especially visible when inserting the custom fieldtype in the global registry:

$.org.kauriproject.forms.fieldTypes.putAll( {
  'mycompositefieldtype': {
    base: 'string',
    control: {base: 'input-control'}
  }
});

and inspecting the value of $.org.kauriproject.forms.fieldTypes._reg["mycompositefieldtype"] before and after the creation of the first form.

On a side note, the error that is thrown is caused by the function AbstractContainerControl.prototype.createChildControl in control.js (line 1895):

...
  if (type.control != null) {
    if (typeof type.control == 'string') {
      controlType = type.control;
    }
    else {
      if (type.control.constructor == Array) {
        controlType = type.control[0];
        extender = type.control[1];
      }
      else { // item = {base:'string', ...extensions.. }
        controlType = type.control.base;
        if(controlType==undefined)
          controlType='composite';
        delete type.control.base;
        extender = type.control;
      }
    }
  }
...

If type.control.base is undefined, the control type defaults to composite, but this is not a valid control type. We believe it should be composite-control.

[jgou]

Checked some more and noticed that next to the found bug mentioned above, the second occurance of an existing child-control-type should bypass the control-type creation.

Therefore a test should be added (comparable to the isReadyType() for field-types) to check that the controlType for the child to create is ready for usage.

[jgou]

priority changed to ++, should not be too much work considering the amount of investigation already done

[freya]

Solved in r1466

Possible via nullable and null-text:

"+validators": { "required": {} },

"control": {

"base": "case-control",
"nullable": true,
"null-text": "--- please select ---"

}

[idbr]

I think this belongs to issue #219.

Replying to freya:

Solved in r1466

Possible via nullable and null-text:

"+validators": { "required": {} },

"control": {

"base": "case-control",
"nullable": true,
"null-text": "--- please select ---"

}

[freya]

It sure does, and this one isn't solved (yet)

I think this belongs to issue #219.

Replying to freya:

Solved in r1466

Possible via nullable and null-text:

"+validators": { "required": {} },

"control": {

"base": "case-control",
"nullable": true,
"null-text": "--- please select ---"

}

[mpo]

Should be solved in r1473
Please crosscheck with your sample and report back.

[idbr]

With the same test-case as above and kauri build r1474, I get the following error:

type.getMemberTypes is not a function
var memberTypes = type.getMemberTypes(); 

which refers to line 92 in composite.js

[mpo]

r1476 adds the test to the samples & puts down one more fix.

[idbr]

I can confirm this is now solved!