I've played with the current dev version of Field Collection and feel that this module has very strong potential in becoming a future potent component of extending fields. I like that a lot.

With the ability to input field entries into the sub-form/embeddable field directly on the create/edit form, coupled with the auto-complete term reference addendum, it does almost everything I would regularly require.

However, I'd like to suggest the addition of an additional extension of the auto-complete feature, and that is...

I would like to be able to auto-complete or select from a list in one field, and have the other fields propagate with related data based off of the first.

Ex.

Field Collection contains:
Name, Phone number, Address

While inputting on the form, instead of having to type into all three fields, I'd like to either select from a list of names in a drop down or type the name with auto-complete, select the name of choice (which shoes the related phone number and address as well, to differentiate multiple entries of people with the same name), and have the related phone number and address fields auto-fill.

Jquery has been able to do this for quite some time already, but I am unsure of how to get this into the field collection module myself, as I have no module writing experience. I hope someone can either provide some direction on how to achieve this or maybe work on a solution for this...

How hard/easy is this to do?

Comments

tim.plunkett’s picture

tim.plunkett
he/him
Primary language English
Location Philadelphia
CreditAttribution: tim.plunkett commented
Priority: Major » Normal
jmuzz’s picture

jmuzz CreditAttribution: jmuzz commented

It could be done, but it seems like it would lead to some unnecessary duplication of data. If one value being the same implies that the rest of them should be then perhaps you should be using a reference to another entity instead of a field collection. For example, what would happen if somebody's phone number changes in the example you've described? Ideally you should only need to update this in one place.

I think as they work right now, field collections are most appropriate when the data they hold is unique to the entity instance holding them.

Having said that, I would be in favor of extending the functionality of field collection so that one of them could be used as a reference to be shared by multiple entities. It does seem to be the closest thing to a generic, multi-purpose fieldable entity that is out there right now, and tying each instance to a single field in a single parent may be an unnecessary limitation.

jmuzz’s picture

jmuzz CreditAttribution: jmuzz commented
Status: Active » Closed (works as designed)

My thinking about this has changed. Field collections are set up to behave as though they are part of the node's data and not a reference to a separate entity, though that is how they are implemented. I think it should stay this way, as it has its own advantages such as allowing proper revision control on entities using field collections. There are other solutions which are looking into other approaches, for example paragraphs has some threads about reusing paragraph content and allowing the user to make a library of paragraph content items to use.