I believe that behavior of this module could be achieved like this:
- Create new content type
ContentType. - Create new entity type
ComplexFiledType(field collection). - Create new reference field
referencethat linksContentTypeandComplexFieldType. - Require
referencefield to linksContentTypenode with only 'dedicated'ComplexFieldTypeentity. That is,ContentTypenodes CANNOT reuseComplexFieldTypeentity that exists and belongs to other nodes.ContentTypenodes must createComplexFieldTypeentity that belongs to them and only them.
I also believe that point 1, 2 and 3 are easier to achieve, and point 4 represents some efforts into References module. At this moment References works with nodes and users, but not with entities. Some work on widgets needs to be done to accomplish behavior proposed in point 4.
The whole advantage seems to be more flexible module that reuse existing functionality like References, Views (relationships). I mean by using references one can link to many entity types (ComplexFieldType1, ComplexFieldType2, etc.). (Views module still makes use of fields so it's not the problem.)
Field collection is fixed so I couldn't find a way to have different field collections applicable to the same field.
Comments
Comment #1
mki commentedI am sorry for creating duplicate of #939836: combofield / fieldentity / field-collection / embeddables. I will probably post some thought there.
Comment #2
donquixote commentedJust saying, this would have to be an entityreference field from the ComplexFieldType to the ContentType.
Like this, point 4 is for free.
And all of this is already possible.
(ComplexFieldType also needs a weight field, to determine the position within the ContentType entity)
What's missing then is a widget on the node form for ContentType, that allows to edit all entities of ComplexFieldType that point to it.