I will explain this simply as I am no systems wizard. Basically, can what this module is trying to do be done instead with Views, content types and a reference module?

1. Say I have a host node of content type "shopping", and a variety of other (sub)content types such as "food", "clothes", etc.
2. On the host node I can add/attach a (sub)node, which in the case of "food" has the fields "type" (eg. Chocolate) and "quantity" (eg. 2).
3. A relationship/reference is created (automatically) between the nodes.
4. I use Views to pull-up the food, clothes, etc. on the host node.

So can modules like Relation and Views field be used instead to fill in the gaps?

Comments

GlitchFreak’s picture

Yep, the module basically works in the same way of doing the things you described.

The way it is different for me is that I can have a single form (course) and I can add related nodes to it directly (members attending the course) on the same form. It saves one from having to create the one node (course) and create all the additional nodes (members) that relate to it. From an input UI point of view, it makes it easier.

blenny’s picture

Let's say the relation/reference module had the functionality to redirect back to the host node after a user creates (or edits or deletes) a related sub node, and assuming the "create relationship/add record" button will be on the host node. Would this then be equally effective as field_collection?

Then it would just be a case of disabling the Title field of the sub nodes.

JohnAlbin’s picture

The use case you describe can be done by field_collection, but that's not the only use-case for this module. For example, see #1333230: Building complex HTML5 fields with fences and field_collection

Are you trying to make an argument that field collection should be deprecated? or that the other method should be deprecated?

From a workflow and setup perspective, the Views + node ref solution is the one we used in D6 and, frankly, sucked, but was easier than creating a custom field type. Field collection is better when what you want is a complex field on an node/whatever.

blenny’s picture

Given that Relation's goal is to be the "go-between" model for pieces of content (entities), I figure there may indeed be a case for deprecation at some point in the future:
"Drupal (core and contrib) maintains too many different (inefficient) relation models (node authors, node comments, comment replies, entity references etc.). The goal is to replace them all with Relation module."

Field collections should be relocatable to their own View page, for example a Journal field collection (date, notes, media) doesn't necessarily have to load with the parent node where instead a link to the View page/stream may suffice. I guess now you could essentailly hide the field from display, then use views bring it back up where you need it. Views can also page content streams.

Another example is the case for a node gallery. The more generic relationship model that a module like Relation permits means I can have a node containing a single Image, add Caption and Tag fields, and it's then super easy to create a views query to display it anywhere. I don't know how to do this with field collection, although better Views integration may take care of this.

Then all Field Collection needs to do is add or remove the relationships behind the scenes, and by routing add/edit/delete requests.

So then Field Collection could be logically renamed Relationship Collection/Connection, or simply merge with the Relation project itself.

blenny’s picture

Assigned: blenny » Unassigned
jmuzz’s picture

Issue summary: View changes

I would be in favor of some of the changed proposed here. Field collection essentially has 2 sides:

1 - A field type that can be put in to another entity.

2 - A fieldable entity to be referenced by 1.

I could see 1 being replaced by something implemented by the Relation project if it provides the same level of UI convenience (ex. embedded field collections). If that were to happen, field collections itself could be changed to a module that simply provides a generic fieldable entity. Even if this were to happen, I don't see why it should become a part of the relationship module. It could be desirable to create instances of field collections without relating them to another entity, even if that is not currently possible.

It was also mentioned to replace 2 with Nodes. I don't like that idea. Although it would be possible to use any entity type as a generic fieldable object by ignoring the data and functionality you're not interested in, nodes are not designed to be used this way. They are meant to be individual items of site content, and they have a lot of extra stuff added to support this that you wouldn't necessarally need in a generic custom entity. For example:

- It's not easy to remove the title field
- They have values for things that wouldn't make sense on many field collections (promote to front page, sticky)
- By default all nodes are indexed by the drupal site search engine.

jmuzz’s picture

There is a more up to date discussion around these topics in the linked issue.

I no longer think that field collection should be made more like a generic entity reference solution as there are other modules that are trying to do this.

Treating the inner data as a part of the node and only allowing field collection items to have a single host has its own advantages such as allowing full revision support by tying each node revision to unique revisions of its field collection items.