roadmap

This was exactly the solution I was looking for - in theory :)

Surely first priority now is to properly integrate with cck, such that sub-types are actually saved to the proper cck tables and referenced.
Putting the reference in the subtype back to the parent seems to work better with views by default - but my understanding of Relationships in views 2 isn't very good.

Great proof of concept and with a lots of work and tlc, would be under serious consideration for inclusion with cck imo.

Good work :)

As of 5/5/09, the high-level roadmap is:

1) work on views integration, better date module support, and conditional_fields module integration
2) keep releasing alpha versions that address above, fix bugs, and provide better integration support with other popular modules (I'm relying on the issue queue to know which ones are not working)
3) move towards a stable 1.0 release that has good integration with cck, views, and the most popular field modules
4) in collaboration with other cck developers, work on getting this functionality into standard cck for drupal 7, in a way that uses D7's much improved Field API, and therefore ought to have solid views integration whenever views for D7 is available

For more detail, follow the issue queue.

I hope that's helpful, and it's subject to change, based on community feedback.

Views integration is in-place as of alpha5. Next up: integration with date module, conditional_fields module, nodereference_explorer module, and other issues in the queue.

Keep up the good work :)

Looking at the roadmap for this module and the Combo fields feature that is under heavy development for CCK 3.0, it seems there are a lot of similarities.

I have read this article but I am curious to know the developers thoughts on where the roadmaps cross and where they divide.

Indeed, I just tested CCK 2.4 + flexifield and CCK 3.x-dev (the multigroup module is not available for 2.x) and also was curious about this.

Both modules seem to do the same thing, BUT with flexifield seperate content-types are needed for each fieldgroup.
See also this comparison: http://drupal.org/node/324929

edit: I guess you will tell everything about it in Paris ;)
http://paris2009.drupalcon.org/session/content-multigroup-and-flexifield...

I'm there!

@askibinski Please note, that comparison is outdated and simply wrong.

Last I checked Content Multigroup wasn't allowing multiple value fields in multigroup, probably because it uses delta (that usually serves as item id in multiple values setup) as group id. That means, you can't use such powerful modules as Content Taxonomy, because each term is essentially "field value" and multiple terms == "mutiple values".
OTOH, Flexifield allows any number of values in single flexifield. So Flexifield is much better (atleast, for me it is).

@crea
I think that issue (at least with content_taxonomy) is now fixed.
http://drupal.org/node/486500

And how is that fixed, when markus_petrux in comment #18 says clearly:

The only caveat is that you can only attach a single term to an item when using taxonomy fields in multigroups because CCK can only support one dimension of delta values. Each field accept multiple values, but under the context of multigroups, each value is managed from its own subgroup in the multigroup.

That means you can't add multiple terms to single "row" of multigroup (which they call "subgroup") while with Flexifield you CAN add multiple terms to single flexifield item.

Example of difference:
Lets say your site has "city" node type. For this node type you want to enter multiple shop descriptions, where each shop contains list of products it sells. With Flexifield solution you can set up Flexifield that will contain information about shops. Each Flexifield item will contain entry about single shop. Lets say, shop sells fruits: apples, oranges and bananas. With Flexifield each shop can have list of fruits it sells as Content Taxonomy field (with fruit names as terms). And with multigroup, you can have list of fruits for each shop too, but each shop will only have single fruit in the list, cause $delta used to select fruit in the list is already used as shop ID.
Does it make difference more clear ?

Crea seems to be right.

I posted the same question in the CCK group: http://drupal.org/node/539210
You can read markus_petrux's answer there.

how can I unsubscribe from this?

Thanks for elaborating on this one! It's completely clear now.