Use cases and features

I think your module aims the same as http://drupal.org/project/field_collection.
Take a look at http://drupal.org/node/939836 , discussing "combofield / fieldentity / field-collection / embeddables".
In comment #10 you'll find a printscreen for the UI.

I have 2 use cases:
1. An entity has a multiple value-field, and each field should have multiple columns, e.g. Recipe with 3 ingredients (name/quantity/unit). The value-field hase no use of it's own, so no separate Entity should be required. However, the columns must be usable for Views/SQL. (Find all recipes with 'butter').

2. An entity has a relation with another entity. This relation should be fieldable. This is what 'Relation' aims for.
In fact, for this, a separate entity with 2 node-references fulfills the storage needs.

IMO the UI for both use cases is the same, and should resemble like 939836#10.

I would also be interested in a discussion between blup and fago (field_collection). It seems this is similar to field_collection, except provides a different way of modifying the micro / field collection (outside the parent entity form, as opposed to inside it).

Blup: I can certainly understand your goal, but my impression is that if a "parent entity form" method of adding micro bundle info to / editing micro bundle info within an entity were added to micro, it would cover all use cases of field_collection. I'm sure that's an incomplete analysis on my part, but you get the idea.

Fago is off to a good start, but I can't help but feel he is spread too thinly amongst his many modules and I'm sure field collection is less of a priority for him. A discussion would definitely be good, but more importantly I think we need to see progress with one route or another. A multigroup type module seems far too important to not be well on its way.

Blump, have you looked at the 'name' field module at all? It actually reminds me of a specific use case for this module to some extent. One thing I like about that module is that you are given tons of display formatters on the 'display fields' tab in the content type admin area. I feel the display fields tab will be far more useful in drupal 7 than it was in drupal 6, with the ability of unique weights across view modes and so forth. I know you were saying that views will be the primary way of displaying the content, however I just hope display formatters aren't overlooked.

Right, I'm wondering if fago and blup might be interested in collaborating, both making life (ideally) easier for both, making for a more robust project, and lastly/leastly, saving some namespace.

Subscribing

Sub

sub

subscribe

Brilliant! It's working replacement for Profile 2, which is not rejoicing. Fields are avaliable for Views over relationship or directly - it's all I've ever wanted :)

Thank You!

This module sounds like a very good idea. I hope it can be used to comment on taxonomy vocabs & terms too.

+1

my aim was to have micro bundles as content SEPARATE from the parent entity, not within it.

This should be on module's front page. Looks like it's time to make separation of use applications between

• Micro
• Field collection
• and others which is not even alpha'ed yet :)

Maybe it will be better to combine all those modules, guys, into one flexible thing, which could solve either challenges with separated sub-entities or with embedded "table part" within node type.

Anyway, just passed in the search of solution for simple case:
Recipe as node type, with ingredients.
ingredient consist of product itself (term) and weight of.
All recipe should be created on one page (node/add/recipe) with or without ajax forms it doesn't matter. 1 thing to keep in mind - end user workflow.

Also interested to see where this goes. I posted a suggestion: #1074424: Add form to the entity edit form, maybe if were configurable per micro type whether it was separate or inline within the form, maybe if Multiform or Subform is available (to offload that code).

Agreed with #15.

I haven't actually tried out this module yet, so please forgive my ignorance.
I have a use case in mind and I wonder if this module would accommodate it.

I have a site on which I have some articles. These articles can span multiple pages and I currently use the module BookMadeSimple to ensure that article nodes can have multiple pages added to them, but only to a depth of 1 (and only of the article_page content type).

This works well from the point of view of the user viewing the content, but the interface for actually constructing these articles is a bit clunky - I'd prefer to have everything managed on one edit page.

Would it be possible to construct a micro entity that would serve as a 'page' within the parent article entity?
From the project description I think this would achieve want I want from the edit page but I am unsure whether I would be able to get the desired result when viewing the content.

Use a existing micro:-
May be if we can use the existing "micro node" (like node reference) but the whole micro get inserted into it..
What I want is to associate a node like (Artist with some info) in my event type node page, So if I have "Artist micro" that can be attached to my Itinerary with his basic details...

Sub. I wish I found this earlier, I've written my own module to do a specific use case of this one... albeit the user rather than the administer has the ability to add / remove attached micro-entities from a list of [administratively filtered] micro-entities on a per instance basis.

Or for an easier description using the profile example, the user has the option to decide which categories they want to be able to edit / display.

+1

I'm currently confused by the number of D7 modules that are trying to solve similar problems. I'd like to explain my use case to see which approach fits the best. I've read the source code to the Field API, Entity API, as well as the Relation, Entity, Field Group, Field Collection, and Micro projects, but since I'm new to Drupal, I haven't been able to make the distinctions I need. The Micro project caught my interest, but then I came across all these other projects. In some cases, there appear to be several names for the same concept (e.g. content type, node type, bundle), so I'm spinning my wheels quite often. I've built web apps with Java and Oracle before and I'm trying to make the conceptual leap to D7.

My use case requires the ability to optionally add spatial and temporal dimensions to a node or a relation, along with possibly other sensory data from a smart phone or other sources. Each dimension would consist of a group of fields that could be applied to any entity. I'm using the word "dimension" in the data warehousing sense of the word, where a dimension is a companion to a fact table. Instead of just having a single datetimestamp field for temporal data, I need to have separate fields for year, month, day, hour, minute, second so functional date computation on a single datetimestamp field wouldn't be necessary at query time across millions of rows. I'd rather pay the penalty on insert. Likewise, the location dimension might have the following fields: hemisphere, continent, country, state/province, street, city, postal code, lat, lon, etc..) I'd like to be able to "slap on" a location dimension and/or a time dimension to a single node or a relation to qualify them. There could also be custom entity types that would need to be associated with dimensions as well. I'd also rather not add all these fields to a relation type since the dimension wouldn't' be relevant for most relation or node instances.

I'd also need the ability to access a "sub-form" from the node or relation for CRUD operations on the dimensional data during development. Any guidance will be appreciated.

I also posted this use case in the field collection issue queue, looking for nibbles.

Subscribe

Project now moving ahead again. Suggestions welcome. See #1477882: Roadmap to 1.0.