Hi,

I am working on something similar: fieldentity. I was planning on using that for bjaspan's combofield (#939834: Fieldentity & subform). I already have some code for that one too. To get this working we really need something like your subform_element module. I am currently working on that, but was hoping to hijack the subform module (I like that name better) for that (#939832: D7). I think I can get ajax working for subforms too. What do you think?

Comments

Title:combofieldcombofield / fieldentity / field-collection

let's discuss the differences, pros/cons here.

Title:combofield / fieldentity / field-collectioncombofield / fieldentity / field-collection / embeddables

How does embeddable work:

* It has an 'embeddable' entity type and an embeddable field type.
* The embeddable field contains references to the embedded entities.
* The name of the embeddable field containing the references is the bundle for the embeddable.

Storage:
* Fields are stored in the used field API storage as usual
* There is a single "embeddable" db table holding ids + field_names for the embeddables (via the entity CRUD API)

UI:
* As of now, the widget is hidden.
* The default formatter just lists referenced entities + provides some basic add/edit/delete links.
* Plans: For editing via formatters, using views would be nice. Embedding the form via a widget would be nice too but is hard. ( + we need to avoid recursions here).

Any pros/cons to other approaches?
I'd prefer very much to join forces with others, so that we can share different approaches for the UIs.

subscribe - the 'fieldable field' space indeed seems a bit crowded with separate attempts, where the respective targets and differences (and possibly inter-dependencies ?) are indeed not clear.

Barry's combofield aims at the same use case than CCK D6's experimental "Multigroup" (although with a completely different approach) : a field whose values are "2 text values + 1 number + 1 image", keeping the sub-values associated across deltas.
To my knowledge, it is proof-of-concept code for the data model, from september 2009, which he did not touch since then (and is probably partially stale since Field API moved a bit since then), and which I don't think he intends to develop and maintain himself.
IMO, can be considered as abandoned, but with possible good ideas or code to start from.

an.droid's 'field collection' (http://github.com/an-droid/field-collection) seems to share the same goals and approach.
Screensot : http://drupal.org/files/issues/field-collection.png (from an.droid in #942310-9: Field form cannot be attached more than once)

Not sure about fieldentity and embeddables.

One possible difference : the goal for combofield / field collection is to make the 'intermediate entity' as transparent to the user as possible - the metaphor is "field with subfields, all attached to the top level node". The user is not aware he's editing a separate entity (discussing the concept with Barry, we came to the conclusion that 'combofield' = 'ghost-entity reference field').
The name and description of the Embeddables module suggests that it might not target at this level of transparency ?

All approaches seem to stumble on the widget side, because of the way Field API forms puts business data in $form_state, in a way that clashes if the form contains different instances of a field.

There's work-in-progress in #942310: Field form cannot be attached more than once to alleviate this limitation in core.
It seems fieldentity is/was considering using http://drupal.org/project/subform_element to work around the issue - which looks like a bold bet ?

Subscribing

subscribe

subscribe

+1 to yched at #5 and #6

I can't look now at embeddables and fieldentity, but IMHO, all 'fieldable fields' should be based on:
1) New field type, which can be configured through Field UI as any other fields.
2) New (hidden from end user) entity type, which will hold all sub-fields.

'Field collection' is following this approach. And as I can see from description in #4 Embeddables using this approach too. However yched's opinion about Embeddables in #5 is make sense for me...

In 'Field collection' I'm mostly trying to focus on how it should be presented for user. So thats why I even called it 'Field collection'... IMHO this is quite intuitive.
The user can define different collections of fields (which are bundles of hidden entity type) and embed them in existing entities, commonly nodes, of course. Collections are managed in the interface similar to one which node types has.

However for now I see two major problems which should be solved in order to get powerful and solid solution.
First is the limitation in fields system described in #942310: Field form cannot be attached more than once. It's work-in-progress and I think we're very close to fix this.
Second is the widgets. Any fieldable field requires at least 3 different widgets for 3 different cases:
1) For 'fieldable field' with cardinality = 1. This is the most simple case, using 'fieldset' to group sub-fields would be quite sufficient.
2) For 'fieldable field' with cardinality > 1 and very simple collection of sub-fields (mostly single-valued sub-fields with simple widgets). In this case 'table view' is the most effective solution I think. Example of such 'table view' is presented in screenshot: http://drupal.org/files/issues/field-collection.png .
3) For 'fieldable field' with cardinality > 1 and collection of sub-fields which has: multivalued fields, fields with complex widgets (e.g. file or image). 'Table view' is not the best way to present such a collections. For this case I have an idea of 'new generation vertical tabs', which behaves much more like tabs we have in all modern web-browsers: tabs are draggable and has one extra tab for '+1'. So navigation between items of fieldable field (I call them 'collection items') is kept easy and robust.

That's it.

I'll look at Embeddables and FieldEntity later today.

Well, at this point I think that Field collection and Embeddables are quite similar internally. While FieldEntity is positioned as an API project.
However I'm a little bit confused by the name and description for Embeddables and not sure about similarity of the goals with Field collection.

fago, what do you think?

UPD:
I'm also not sure about UI part in #4.
'Field collection' will embed collection items in hook_field_widget_form() of 'field_collection' field type.
The only limitation is that 'field_collection' field can't be added to any bundle of collection entity type. However, I think this functionality is redundant.
The only problem here is that we can't use field_attach_form() because it immediately embeds recieved sub-form into provided $form argument, while we need only to return that sub-form. But we can use _field_invoke_default('form',...) instead...

BTW, Field collection is the only project I have now and it's also one of my main interests, so I'm planning to work hard on it and hopefully release first stable version together with D7... so I'd like to join forces with others too.

Just re-read #32 from #942310: Field form cannot be attached more than once by fago... I need to take a closer look at Embeddables...

The summary of embeddables is in #4, I'd be interested in similar summaries for the other projects so we might come up with some other technical differences?

@combofield

IMO, can be considered as abandoned, but with possible good ideas or code to start from.

I had a look at it before starting the project, but I considered it abandoned too + read that barry considered the approach as very hard to implement even for someone known field API.

As I didn't see any problem with the approach of using another, invisible entitiy, I've gone that way. This also has the advantage, that you can save embedded entities independent from the rest of the "host entity".

One possible difference : the goal for combofield / field collection is to make the 'intermediate entity' as transparent to the user as possible - the metaphor is "field with subfields, all attached to the top level node".

The add & reference part is and should be definitely transparent, however my current use-case does not impose having the form embedded. Instead I need some simple add/edit/view links on node/entity view. So the module currently just establishes the data structure + implements a simple formatter and associated forms for the add/edit/view operations.

Thus for embeddables, it should be a possible feature to edit the embedded entity on its own. As a consequence users should be probably aware of the separate entity, but I'm not keen on using the current terminology.

@differences to field-collection:
Embeddables are created by adding an embeddable field, then you can go to admin/structure/embeddables and edit the embeddable fields there. That way you can easily attach an embeddable to any fieldable entity. Ususally you'll add a new one per entity, but if you like - attach the same field again elsewhere. Then, as it is a field, we have widgets and formatters. I very much like having that pluggable, so we can simply write different widgets for solving the "embedding the form" problem.

From what I've seen the creation part works different for field-collections?

Fieldentity contains an dedicated entity controller and an field storage backend that delegates field storage to fields' entity controller.

Modules like combofield, embeddables and field-collection could depend on it, while still have control over their database schema, field info and entity info.

Advantage of fieldentity would be that it automatically integrates those fieldable fields with fago's entity module (full crud, exportable, etc).

Overall I think combofield, embeddables and field-collection all have the same structure; a field that is also exposed as an entity.

Ok, here is summary for Field collection:
How it works:
* Literally it defines 'field_collection_item' entity type, which bundles are 'field_collections'. This is very similar to nodes and node_types internally, but much more simpler. 'field_collection_item' table only stores information about unique ID of the item and machine-name of the 'collection' it belongs to. UI for collections are also very similar to UI of node types.
* Second is 'field_collection' field type. This field type has only one setting for now - 'collection_name'. User can choose from one of defined collections. Selected collection will define set of sub-fields which will be attached to the form. Field only stores reference to the unique ID of 'field_collection_item'.

Storage:
* Fields are stored in the used field API storage as usual (the same as Embeddable)
* There are two tables: {field_collection_item} holding IDs + collection_names; {field_collection} holding title, machine_name and description for collections.

UI:
* As of now, there is one test widget 'Table view'.
* There is no formatter yet.
* Plans: create at least 3 different widgets for 3 cases described in #10. Formatters should be different too. Views formatter is nice idea too.

Differences with Embeddable:
* for Embeddable field itself is a bundle for 'embeddable' entity type, so field name as used as bundle name. Field collection manages 'bundles' separately. Don't know is it actually necessary, need to think more about it. However, Embeddables approach is interesting. :-)
* Embeddables are edited in separate form (for now). I think it's not acceptable at all. Fieldable fields must be edited within form of the parent entity. That's one of their main purposes, I believe.

My thoughts:
* One thing that I'm actually don't like in Embeddables (sorry, fago) — it's the name 'Embeddable'. Especially when I'm thinking about how to translate it to other languages. I even can't pick up right word to translate it to my native Russian (well, I have one, but it's really funny :-) ).
* Recalling discussion in #937814: [meta] Smarter UI/API separation for modules. I'm mostly with webchick there. Well, personally, I think that there is no reason in the world to create lots of different UIs for one particular feature. We need to create one, but perfect. However, there are cases exists where we can have two UIs (like SimpleViews), but it's an exception to the rule. So, IMHO, 'fieldable fields' should have excelent UI as part of the main project.

I'm not familiar with the underlying design ideas, but I would highly recommend to stay away from (ghost) entity references. I don't see why or how they are required or relevant for this task. AFAICS, the goal should be intra-entity cross-field-instance references.

Thanks for sharing the details.

ad #14:
Interesting. Embeddables also uses the entity CRUD API, however the database table only contains the id and the field_name (probably we should add revision id + language too). Generally, embeddables try to build upon the field storage backends for storage, while fieldentity seems to try to build upon the entity controller for that.

So a difference would be that with embeddables, you can switch field storage backends per entity as you prefer, so the host entity and the embeddable could run with mixed storage.

@export:
As embeddables are configured as a field, exportability isn't so problematic. Features is already able to export field instances and embeddables is already working fine with that :)

ad #15:
It looks like embeddables and field-collections pretty much work the same way, except for embeddables to be automatically create via the field instance - thus as said, there is nothing like the additional "field_collection_item" entity type.

ad #16: Do you any details about that works + what is better with that approach ? Imho behind-the-scene entity references fit very well to what we want to achieve.

Embeddables are edited in separate form (for now). I think it's not acceptable at all. Fieldable fields must be edited within form of the parent entity. That's one of their main purposes, I believe.

I very much disagree.

For me embeddables was the solution to the "multiple profiles per person" feature I discussed with others for profile2. A profile is always unique per person, but with embeddables e.g. you can attach multiple contact addresses to it. Or multiple albums to an artist node. You know the story.

The point is, what is common to all those scenarios is the data model. It's about an entity, that belongs to another entity and has no right to exist alone. ;) It's the same as composition in UML.

However, the end-user UI for this is rather tricky and the right UI higly depends on the specify use case. In some use cases, you want to have add/edit/delete buttons on view, on others on edit. On others you want to embed the form on edit in different ways.
So, embeddables have thanks to the field API by design pluggable UIs. What should be the default is another question, but I don't think it's very important for the potential users (nor for me).

Admin UIs are somewhat different here. We need to have good out of the box experience there, but this is about end-user UI which needs to be very flexible.

But I agree, for doing "fieldable fields" I'd assume it comes with an embedded edit-form UI. So perhaps the difference is, that embeddables is conceptually broader, it's intended to not only fit for fieldable fields, but also for the add an entity and automatically reference it somewhere use-case.

* One thing that I'm actually don't like in Embeddables (sorry, fago) — it's the name 'Embeddable'. Especially when I'm thinking about how to translate it to other languages. I even can't pick up right word to translate it to my native Russian (well, I have one, but it's really funny :-) ).

I picked embeddables, as it fits to the concept of an entity embedded into another one. As said I'm not keen on that and I'd be happy with another better name too. Probably field-collection is more user friendly and describes it pretty well too?

subscribe

Fieldentity doesn't set the storage backend for its subfields, just for the fieldable field. Fieldentity allows using one table for both the entity and field data.

Embeddable uses its own embeddable table for the entity but uses an extra table (depending on the storage backend) for the field?

>Fieldentity doesn't set the storage backend for its subfields, just for the fieldable field. Fieldentity allows using one table for both the entity and field data.

Ah, got it. :)
Yep, embeddables stores basic information for being able to reference back to the host entity (currently only field_name, revision id + langcode has to be added too). I thought about using the field's storage directly for the entityfor that too, but there is no unique entity id to reference by default. I see, that's doable with a separate storage controller, but I'm unsure whether it's worth the troubles as I don't think the separate table with the necessary info to look the entities up hurts anyone.

>Embeddable uses its own embeddable table for the entity but uses an extra table (depending on the storage backend) for the field?

Exactly. There is a field using whatever field storage for referencing the embeddables + a db table for looking up entities upon entity_load().

Hey, all. Been following the whole 'multi-field' fieldable fields thing pretty closely. Seems like this is the place to be to discuss it!

For the purposes of this post I'm going to use the term 'field-collection' to refer to the concept of a combofield / field-collection / fieldable-field

@fago #17:
So @an.droid is suggesting that the form for adding/editing the field-collection should be nested within the add/edit form for the node. But you're suggesting that there may be use-cases where you will need to edit the field-collection data somewhere else... For example, maybe you'll want to add the editing widget for the field-collection directly on the 'view' screen of the node it's attached too instead of the add/edit node page. Am I following you correctly on this one? If I am, I think this is a very good point. However, the feeling I get from reading about what people are doing with something like the experimental 'multigroup' for cck3, is that most use cases are centered around editing the field collection along with the node it's attached to. Furthermore, you mentioned:

it's intended to not only fit for fieldable fields, but also for the add an entity and automatically reference it somewhere use-case.

Are you thinking along the lines of something like 'nodereference'? (Only in this case it would be more like entityreference without any of the extraneous node data)

@all:
Regarding the UI for a field-collection, I've always felt a really nice solution (at least for having the editing widget embedded in the node add/edit form) is the way multigroup is currently doing it in cck3. The UI design for that is pretty well perfect for a simple field-collection. Users can create a multigroup right in the 'manage fields' view. Of course this has its own set of limitations (e.g. can't nest groups in groups, only single value fields per group)

It seems there's a few categories of use cases for a field-collection module:

1) a 'Multigroup'-like solution where people just need a simple group of single valued fields
2) a solution like an.droid's field-collection module that allows for *limitless* nesting of field-collections in field-collections and can contain either single value fields or multiple value fields
3) the embeddables solution where the functionality is much the same as an.droid's field-collections, but broader (see comment #17)

Does it make sense to devise a solution that can cover all these use cases in one module, or would it be better to consider keeping each use case covered in it's own module? IMHO I think that there's a *lot* of people whose needs don't go beyond use case #1...

wow, lots of info here, did not fully parse yet.

For now, just reply @sun #16 : "stay away from (ghost) entity references. I don't see why or how they are required or relevant for this task - the goal should be intra-entity cross-field-instance references"
[I don't understand what that last part.means :-)]

'Fieldable field' is only one of the approaches towards the Mythical Graal of Compound Field (let's call that MGCF) : "I want a field whose values are [one string + a number + an image] without recoding a corresponding field type+widget+formatter".

That approach, de facto, means 'reference field', follow the math :
'fieldable field' = fields whose values have fields
= a field type whose values are fieldable entities (let's call this entity type "X-entity")
= a field type whose values are ids of X-entities - because an X-entity is nothing more than its unique ID + its field values
= an "X-entity reference" field
And Barry's "combofield", fago's "embeddables", an.droid's "field collections" all come to this point.

That's possibly where Embeddables and Field collections differ, though : from what I get (fago, an.droid, correct me if I'm wrong)
- fago intends its X-entities to exist on the site (viewable, editable, reusable on other nodes...). Here, X-entity could be called "content snippet". They are visible animals in the site (even if only to admins or editors) - a pretty bare fieldable entity, with none of the behaviors of nodes, users, comments etc...
- an.droid intends its X-entities to be real "ghost entities" : they are fully 'transparent', and have no existence of their own on your site, other than to hold values for a sub-part of a node.

For the record, other approaches for MGCF are (to my knowledge) :
- CCK3's multigroups : regular fields, with heavy form and display manipulation to group values by delta first rather than by field first. With high respect for Markus Petrux and the amazing work he did there, I consider this to be a hack - the most clever hack that was doable with CCK D6, but a hack.
Only allows single-valued child fields (i.e one value per delta).
- aggregated field : a field type whose storage columns are the aggregation of the columns of its component fields. There hasn't been any attempts that I know of, but I'm sure this comes with its own set of tricky bits if you pull the thread.
Only allows single-valued child fields
- serialized field : http://drupal.org/project/flexifield (I was stunned to see its was effulgentsia's :-p). a field type with one single data column, holding a serialized array of sub field values.
Probably allows multi-valued child fields. Obviously, not Views-friendly.

IMO only 'fiedable field' and 'aggregated field' are still potentially solid options - and that's quite possibly because 'aggregated field' has not really been investigated so far.

@yched: Regarding cck Multigroups

...I consider this to be a hack - the most clever hack that was doable with CCK D6, but a hack.

Though it may be a hack, I still think the idea of creating the multigroup through 'manage fields' is the best way to create field-collections... at least from a UX perspective. Do you agree?

@drclaw - agreed. UI-wise, it's best if subfields are edited on the "Manage fields" page of the top-level entity - at least if the target is 'transparent X-entity'.

That might not be completely easy, though. For instance, moving a field in or out of a field-collection is not possible (that would be re-assigning an instance to a different entity type and bundle - not supported). This notably makes the task of adding a new field to a collection a non-trivial job, since Field UI creates instances on the entity type and bundle of the main page.

For me embeddables was the solution to the "multiple profiles per person" feature I discussed with others for profile2. A profile is always unique per person, but with embeddables e.g. you can attach multiple contact addresses to it. Or multiple albums to an artist node. You know the story.

Oh, I see. That's the point, indeed.
Difference between Embeddables and Field collections described by yched in #22 is correct. So, I think, we should consider is this two approaches can coexist within one project? Technically, I think they could. Because internally there is no valuable difference between them. The problem is in presentation and positioning.

UPD:
It looks like Embeddables and Field collections has absolutely opposite behavior for handling X-entities (I'll use yched's terminology). However I think it's not problem to define an 'Exposed' widget for 'field collection' with options whether to put widget form on the view page or in separate tab/block(?) or maybe add 'local action' for adding X-entities. Since we are talking about 'fieldable fields' then they should behave like fields, hiding existence of X-entities as much as possible.

Also, about multiple addresses, albums for artist and such.
I don't think it's the best solution to provide totally separate UI for editing such information.
BUT, I can imagine situation when I'm on my profile page looking at my addresses and I have an option to 'Add another address'. Clicking it gives me the form (in expanded fieldset or in *box, whatever) which contains only address fields and a submit button. The same way I can be presented with option to 'Manage my addresses'. That's awesome opportunity!
But I still think that it's some kind of 'additional UI', and it must coexist together with standard fields UI (embeded in the form of host entity). Moreover this doesn't contradicts with concept of 'ghost entities'.

The point is not to choose between one UI or another, but to have one standard way to edit 'fieldable fields' within host entity form + additional opportunity to add/edit/remove X-entities in some kind of simplified user-friendly interface.

This possibly can satisfy my and fago's needs (correct me fago if I'm wrong), while staying within principles of 'fieldable fields' and 'ghost entities'.

That's possibly where Embeddables and Field collections differ, though : from what I get (fago, an.droid, correct me if I'm wrong)
- fago intends its X-entities to exist on the site (viewable, editable, reusable on other nodes...). Here, X-entity could be called "content snippet". They are visible animals in the site (even if only to admins or editors) - a pretty bare fieldable entity, with none of the behaviors of nodes, users, comments etc...
- an.droid intends its X-entities to be real "ghost entities" : they are fully 'transparent', and have no existence of their own on your site, other than to hold values for a sub-part of a node.

Exactly. Though I think the "content snippets" approach does fit the fieldable fields use-case too. Isn't it nice to be able to list them separately too somewhere if the need for that comes up?

Difference between Embeddables and Field collections described by yched in #22 is correct. So, I think, we should consider is this two approaches can coexist within one project? Technically, I think they could. Because internally there is no valuable difference between them. The problem is in presentation and positioning.

Agreed, the underlying data structure and concept is the same, with multiple UI options users can just leverage it as it fits their needs.

Project:Embeddables» Field collection
Version:7.x-1.x-dev»

So me and an.droid have agreed upon joining forces on the project with the name "field_collection". :)

Awesome ! That's great news. See you in #942310: Field form cannot be attached more than once folks :-p

As a @self reply to my "list of approaches for Mythical Grail of Compound Field" in #22 :

'aggregated field : a field type whose storage columns are the aggregation of the columns of its component fields'
Won't work in D7, because field types schemas cannot be changed after the field is created. That would mean you cannot add or remove subfields once the compound field was created.

Project:Field collection» Embeddables

subscribe.

Edit:
Sorry, the change of "Field collection » Embeddables" was unintended.
I had the browser page open for some time before I decided to subscribe.

Seems like fago wanted to move this issue to the new project (see #27).

Fieldable fields. I've been wondering about this. :) sub.

> A profile is always unique per person, but with embeddables e.g. you can attach multiple contact addresses to it.

But just to complicate things, you don't want *just* multiple contact addresses.

Each address also needs some kind of taxonomy or flag so it can be one of primary/work/school/personal. A use case I've also seen recently is that some of your addresses might be seasonal (say a summer home) and therefore you want a date field on the address too!

>Each address also needs some kind of taxonomy or flag so it can be one of primary/work/school/personal. A use case I've also seen recently is that some of your addresses might be seasonal (say a summer home) and therefore you want a date field on the address too!

Exactly, add the date field or term reference to the field-collection and you are done.

Project:Embeddables» Field collection

Subscribe

subbing

I can't get the exact goal of this topic.
Is it to give an editor's possibility to add a group/collection himself?
Let's say we have a group called 'members' with fields 'name', 'first name', 'adress','postal','city',...
User gets the possibility to 'Add user' clicking a button. Each user of course has a 'name','first name',...
User gets the possibility to add as many users he wants to add.

Is it to give an editor's possibility to add a group/collection himself?

Yes. Editor will be able to manage field collections like any other field from admin interface. However UI for that is still under development and is delayed due to problems in #942310: Field form cannot be attached more than once.

Sub

@fago, an.droid, just a thought, maybe you guys had that in mind already :

The two use cases identified in the discussion above (1. reusable content snippets, 2. compound-field values in transparent ghost entities) slightly differ when it comes to pruning compound-field values :
- when a node / a node type is deleted
- when a node is updated and a value for the compound-field is removed (field emptied, or node saved with 2 values instead of previously 3)

Use case 1 is pretty similar to filefield : should I delete the referenced resource (file / X-entity) - it might still be in use somewhere. Even if it's not in use anymore, I might want to keep it around for later reuse ?

Use case 2 doesn't need to bother, the ghost entity only exists as being referenced in the compound-field value,, so it can be ditched.

Looks like filefield's reference counting will need to be reused / abstracted out.

@reusable content snippets:
Are they actually reusable? I'm not sure is it really necessary to make them reusable. The difference with files is that files are totally independent from any host entity. But field collection is always created within host entity context. It's similar to node<->comment pair in some way.

For instance, if we deleted user whose profile contained multiple addresses then we don't need that information anymore. The same with artist<->album.

I think in most cases such 'content snippets' has sensible meaning only together with their host entities.

And as I stated in #25 I think we should stay in concept of 'ghost entity' as much as possible. Having additional opportunity to add/edit/remove field collection items outside of the host entity form doesn't breaks transparency of X-entities. Think of it as an in-place editing of fields similar to the menu with gear-wheel-icon we already have in blocks (that's good idea for D8, BTW :-) ), but with different options for where and how we can edit those fields (in separate tab or on view or in overlay or whatever else would be necessary).

Hmm ... in the case of artist/album, I think it is certain there will be cases where more than one artist is associated with an album. Byrne+Eno, say. In that case I'd definitely want a check before deleting all albums associated with an artist, or err on the safe side.

Yes... that's the case.
Well, then we also need to implement appropriate UI to let users create references to existing field collection items.

>"I think in most cases such 'content snippets' has sensible meaning only together with their host entities."

Yep. I designed embeddables exactly with that in mind. If you want content snippets to exist without the host, you wanna have another entity type e.g. "nodes" for that, maybe just use a traditional reference field.

>Well, then we also need to implement appropriate UI to let users create references to existing field collection items.
Let's not complicate things, but make the module suit one case but this one good. As I wrote previously:

The point is, what is common to all those scenarios is the data model. It's about an entity, that belongs to another entity and has no right to exist alone. ;) It's the same as composition in UML.

Maybe we wanna somehow communicate this on the project page? It was the cause for me to call the things "embeddables" - they are supposed to be a part of the host-entity. If the host goes away, the part goes away.

>Hmm ... in the case of artist/album, I think it is certain there will be cases where more than one artist is associated with an album.
Yes, there are use-cases like that. We cannot solve any use case with a tiny module, but there are others too.. ;)

subscribe

Yep. I designed embeddables exactly with that in mind. If you want content snippets to exist without the host, you wanna have another entity type e.g. "nodes" for that, maybe just use a traditional reference field.

OK. So what you're saying here is that embeddables will not be a replacement for CCK3 multigroup functionality? I suspect that is what many users are wanting. A prominent note on the project page would be a good idea.

Personally I have a frequent need for a multiple-value composite field that contains a nodereference autocomplete, a textfield, and a single checkbox or a dropdown select. In this case I certainly don't want the referenced node deleted when the host entity is deleted!

Personally I have a frequent need for a multiple-value composite field that contains a nodereference autocomplete, a textfield, and a single checkbox or a dropdown select. In this case I certainly don't want the referenced node deleted when the host entity is deleted!

And it won't. If you delete host-entity then only reference will be deleted. Referenced nodes will remain untouched.

Thanks for confirming that.

subscribe

subscribing, cool stuff.

Subscribing too

http://drupal.org/project/field_group provides some UI to visualize edit forms and display both. So maybe join some forces with them?

Also I think that combofield / fieldentity should reference to this issue from their front page.

EDIT: What is the difference from http://github.com/yched/combo

What is the difference from http://github.com/yched/combo

yched's module is for testing purposes only for work in #942310: Field form cannot be attached more than once.

And there are no forces to join with field_group. Field_group and combo fields (field_collection) will be totally unrelated things in D7. See my comment in http://realize.be/state-fieldgroup-module-drupal-7#comment-1132
At best, field_collection will do some remotely similar manipulation to integrate with Field UI screens.

This being said, the sentence "field_group and field_collection are totally unrelated" sounds like that maybe we haven't found the right name for the latter yet :-)

Thanx a lot for explanation. I've tested field_collection + combo and it works except internal edit form so following a #942310: Field form cannot be attached more than once

Version:» 7.x-1.x-dev

Subscribe

Will the multigroup use case be supported? I don't need an Add buttot on the node page, but an widget on Edit page

Yes, widgets will be supported. But there are currently limitations in core which must be fixed prior to implementing this feature. See #942310: Field form cannot be attached more than once for details.

subscribe

I have been following this discussion, and for me it is still unclear:
1- can the X-entity also be a 'regular node', instead of a 'ghost-entity'?
2- Regarding the use case of adding Albums to an Artist, would it support the following use-case?
- define content type Artist (with 5 fields) and content type Album (with 10 fields)
- create the Artist form with a field_collection for Albums, enabling to add one album per line, only showing the 3 most important fields.
- now, you should be able to double-click a Album-line, which shows the (complete) Album form.
3- could the X-entity (i.c. Album) also be used from a second main-entity?

subscribing

subscribing

subscribing

subscribing

subscribe

Subscribe

The issue referenced in #58 is fixed, so things are looking up for multigroup in Drupal 7 (looks awesome).

Subscribe

++ on #60, that would be a wonderful mechanism.

subscribe

sounds like music - subscribing!

Subscribe

subscribe

I'm still catching up on this thread, but my two cents so far is that we might need to separate the use cases for this module(s).

We started working on something similar then came across combofield and fieldentity. Barry has only just gotten back to me and pointed out the issue in core that is now fixed.

Our initial use case was something along the lines of "CCK for fields" - basically looking at fields like "link" or "address" which have to be custom coded modules to have multiple form elements in the same field, we wanted to provide a simple way for people to easily make/manage their own complex fields without the custom code.

I feel this is somewhat different than the use case of nodereference or the Artist/Album use case, where you are actually needing to manage multiple entities but want to have a simplified user interface for certain workflows (such as adding an artist and multiple albums).

@ #74: Wouldn't both use cases be covered by the 2nd? I've had projects of both kinds, and I can't think of a time where a system designed to satisfy the 2nd use case would not cover the 1st. The reverse is not true (having a standard entity for each entry would be nice, for views flexibility and other standard things).

It seems like the first case would be covered by the second, especially if nodes of the first type were hidden from the content list and create node pages.

Subscribing

Subscribing.

http://drupal.org/project/micro looks interesting...

subscribing

Subscribe

Subscribing

Subscribe

Subscribe

+1

#57 ... will be nice..

subscr

I concur with #57 and #87.

+sub

subscribe

Another module that hasn't been mentioned is Multiple forms module which is used by Media Gallery to allow editing of media fields from within the gallery node.

subscribe

Very eager to see this made more solid.

Has any progress been made here recently?
As #942310: Field form cannot be attached more than once is resolved this should be possible now?

subscribe

subscribe

subscribe

subscribe

BTW: Here is a checkin about the various options existing today (for Drupal 6) http://groups.drupal.org/node/23899
This includes both within node options and moving into reference relationships.

subscribe

Are field collections going to be able to be added via node creation form?

Would it be possible to use ajax; once title is filled node is created via ajax, and field collection form inputs become available?

Thanks @DamienMcKenna , so much better.

subscribe

So as I understand this module now offers beautiful way to create "multigroups" and now we are trying to figure out a way to include them in node form?

It sure does, but there is some good work being done on getting the subform in the node edit page. There is a patch in this issue that's getting things started, but still has a little ways to go: #977890: Display collection fields within entity form (subform/embedded)

Maybe off-topic, but what are predictions of performance of node with field collection? How much worse field collection make node load if any? How about "multi field collection"? How about field collection with field collection in it? and finally "multi field collection" with "multi field collection" in it? Is this something we should worry about or accept as inevitable faith?

We could use lazy-loading for field collections, then there'd be no performance hit.

subscribing

+1

sub

I just played with both 7.x-1.0-beta1 of Field collection and the one in an.droids github. TBH I am much more in favor of the approach of the one in github than the one here. Having the 'add' link to add a value to your field from within the node page is unexpected. I'm not saying it is useless. I see there are possible use cases with which that could be really handy, but I assume that for 80% of the people who will use this module, the use case will be to just combine two existing fields into one field to use i the node edit form.

As discussed, it would be great if the field collection UI would be available in the regular Field UI (admin/structure/types/manage/[bundle]/fields instead admin/structure/field-collections. Maybe it could be merged into the field settings form (admin/structure/types/manage/[bundle]/fields/[field-name]/field-settings).

I'm currently working on a major project in which this module is required so I have some time to work on this (8-16 hours). @an.droid: Can I fork your Github code as a starting point?

@skilip : #977890: Display collection fields within entity form (subform/embedded)
And, no, definitely don't fork the github repo, the code is long outdated

Issue tags:+ui-pattern

Sub & tag. These field collections will need some ui love.

Issue tags:+Usability

sorry…

subscribing

+1 & subscribing

A major limitation of this module is the impossibility of using different field collections that are applicable to the same field. When using node reference, user can choose many content types that can be referenced.

Field collection seems to be achievable as a subset of existing functionality (entities, references/relations, Views relationships) with some additions/restrictions. That is why I believe this module could be divided into smaller building blocks that could support more use cases.
Module 1: allows to create entity type (field collection) that cannot exists on the site as separate content. (But still, someone can create a content type (regular node type) instead).
Module 2: allows to create a reference field that have one special feature: user can reference only field collection entity that is created and 'dedicated' to a given host entity, and deleted when host entity is deleted.
Module 3: all that user interface candy that is already used and known in node reference world as 'create and reference', 'subform' and the like.

This is possible roughly in Drupal 6 by reusing nodes as field collections and using node references with additional restriction (for example Referential Integrity for CCK).

The bootom line is the feature request: allow to use many field collections for the same field. Thank you a lot for giving consideration to this.

@mki What is the use case for that? How would that be useful for the end user?

I think mki does have a point. If you want to create child entities, it is a good thing to a) choose the interface (module 3) and b) choose the child object - be it a new node, an existing node, or a field collection (module 1). The field definition can restrain the kind of object (module 2).
(IMO field collection has the main advantage of showing a multifield, instead of only showing the title.but it might be a subset of a content type)

@aidanlis – Generally speaking, some properties of objects may have different (incomparable) representation (specification).
Example: When thinking about modeling "Invoice", you may have "Product" field collection with the same set of fields like "name", "quantity", "price per unit" etc. But "Invoice" may have also "payment_method" field. And then we have completely different field collection for "Money transfer", "Credit card", "Mobile payment" etc. All these payment methods involves different field collection, but still represent the same "payment_method" field.

@johnv – Yes, I entirely agree with you. More modular design would be better and resolves issue like "ghost entities" vs. "real nodes".
The problem you mentioned is resolved by use of field formatters for node reference – we can choose to display title, teaser, full node, and also make some custom formatter.

sub

subscribe

// subscribing.

S to the U to the B to the .. ahem, sorry Friday. +1 sub

Is it just me, or does this issue seem a bit useless?
Of all of the listed modules, only field_collection is active: fieldentity and embeddables are both abandoneded, and combofield has no activity for a year.

mki appears to have some good points, but as sun always says, talk is silver, code is gold. If fieldcollection doesn't do what needs to be done, either provide patches, or create a new module that does (and we can have another mini cck-vs-flexinode evolutionary design competition).

In the mean time, the original reason for this issue is surely resolved. Can we close this?

@naught101 : I'd think so too

Status:Active» Fixed
Issue tags:-Usability, -ui-pattern

Well then .... by the power vested in me by the state of new york and naught101, I declare http://drupal.org/project/field_collection the winner!

This issue tracks the status of using field_collection like multigroup/flexifield, this is probably the one worth subscribing to:
#977890: Display collection fields within entity form (subform/embedded)

Otherwise marking as closed.

Status:Fixed» Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.