By bomarmonk on

How does this new multigroup module (http://drupal.org/node/119102) compare to Flexifield: http://drupal.org/project/flexifield ?

I hope I'm not doing anything to unfairly hijack this issue, but I was looking for a place to ask this, and I didn't find too much about multigroup on an initial search.

For me, it would be useful to be able to reuse existing nodes as part of a CCK node (or create new nodes within a node), so I think Flexifield might be the right tool. But multigroup almost seems to do what I want as well.

How I want things to work:

  • Movie Review Node
    • Actor Node
    • Director Node

Where the actor and director nodes can be created within the creation of a movie review node, or added from existing actor and director nodes. Is there a good way to build such a hierarchy between content with CCK? Is multigroup the answer? Maybe these do not need to be nodes, but grouped fields that are reusable? Any suggestions would be appreciated!

⋅ Categories: Drupal 6.x

Comments

markus_petrux’s picture

markus_petrux commented

A field in CCK is often composed of one single form field, than is stored on a single column in the database. But a CCK field can be composed of more than one column. Take for exemple the addresses CCK module, Money CCK field, etc.

CCK2 creates a separate table for each content type where you create CCK fields for it. The key for than table is the vid (node revision), and you will have a record in than table for each node revision. However, CCK2 may create a separate table for fields. That happens when a) the field is reused between several content types (primary key is still the vid) and/or b) the multiple value attribute for the field is greater than 1 (primary key is vid and delta). When a field accepts multiple values, each one is stored on a separate delta. Field tables may store as much column as required by the field definition. It is often 1, but there may be more.

I haven't used flexifield, but it looks like it allows you to create CCK fields with one or more fields that are defined on separate content types. Each of these CCK fields, when put together on a flexifield, will be managed by CCK as a single field. The problem with this approach is that all data is serialized, so it cannot be queried, used in views, etc.

On the other hand, the multigroup module allows you to manage several CCK fieilds in unison. It's like a simple field group, but you can apply the multiple value attribute to the whole multigroup. The fields are still stored in their own database tables. The multigroup allows you to keep the deltas for each field synchronized. The node edit form is like a fieldset that contains subgroups of fields, each being a separate and independent CCK field, but all of them share the same delta value. You can add as many subgroups as you like, and you will be creating new deltas for each field in the group. Since you're using CCK fields, you have full views integration, with tokens and so on, as defined by the features of each separate CCK field used on the multigroup.

Doubt is the beginning, not the end of wisdom.

effulgentsia’s picture

effulgentsia commented

I'm curious, bomarmonk, what you ended up using.

Markus was correct at the time he wrote his comment, that a limitation with flexifield was storing the subfields' data in a serialized string, resulting in no views integration, and other problems. That has since been fixed. A continuing limitation with flexifield is integration bugs with some key modules, like date, but I hope to resolve these as I'm able to devote more time to evolving the module. On the other hand, a limitation of multigroup is that the fields within it can't be multiple-valued, something crea describes nicely on http://drupal.org/node/296463#comment-1892996.

I don't know if it will be accepted, but I submitted a session proposal for DrupalCon Paris to discuss these two modules. If it gets accepted, I'll post the presentation and notes online and will add a comment here that links to it. Even if it doesn't get accepted, I'll work on creating some more documentation about these modules.

One thing to keep in mind with both multigroup and flexifield is that in both cases, submitting the parent node does not result in nodes being created for the grouped fields. One single, top-level, node gets created. In your example, this would mean, that there would be no node id for an Actor, and therefore, no way to comment about the actor, or do any of the other things you can do with nodes. Both multigroup and flexifield were designed for grouping fields, not setting up node hierarchies. For setting up node hierarchies, the nodereference module (part of CCK) is the starting point, and there are several modules out there that try to improve on the UI of doing this (for example, Nodereference Explorer and Popups: Add and Reference).

pendashteh’s picture

pendashteh commented

In case that:

  1. There are a few simple fields you want to be grouped; and
  2. You won't need these fields separately in Views, Menus, etc.

just use Content Multigroup module boundled in cck3; the flexifield is more complicated and buggy for this simple cases.

But if you have a completely separate cpntent type and you wish to add it's fields to another content type'e entry form, it might the multigroup module does not meet your needs and I have got no exact solution for this case.

xatoo_’s picture

xatoo_ commented

effulgentsia,

Did you eventually discuss the above issue at the DrupalCon? I'd like to know if there are any sheets or documentation online regarding the different possibilities in creating node relationships. We're dealing with a somewhat same situation as bomarmonk did, although it might be a bit more complex.

Case:
We would like to have nodes representing articles. These articles can have multiple prices and trade-units (packagings). Trade-units can be added to an Ubercart Cart but the prices of these trade-units will be calculated on the fly. Prices can differ depending on what user is logged in. All the information regarding an article and its prices and trade-units will be displayed on a single page.

Now in order to create the relationship between articles, prices and trade-units we can use the following three methods:

1. Node reference (But presenting a user friendly GUI to add new articles is hard by using this method)
2. Flexifield (I love the GUI, but is this module stable enough for what we want? Won't this be asking for problems with 'child'-elements (like prices and trade-units) not being true nodes?)
3. Multigroup (Same questions as flexifield)

I can imagine that the above case makes view integration important, but as far as I can see all three modules provide integration with views. Furthermore, I don't know whether 'not being a real node' can be a problem for the integration with for example Ubercart.

I would appreciate to hear what kind of views or experiences other people have on this subject.

bomarmonk’s picture

bomarmonk commented

Since multigroup is a development version of CCK (6.x-3), I decided that its approach would more likely be continued into the future. I have been testing multigroup and I have been able to create what I describe above with nodereference fields. Some current limitations include a lack of nested multigroups and incompatibility with vertical tabs, but it works really well with any cck field or nodereference that has some compatibility with its new features. I have created a table view of a muligroup for a flexible set of office hours and this worked rather well. But it does seem that there are some grouping limitations in views at this point (one of which may be solved by nested multigroups or perhaps by offering a couple more options on how to display non-nested groupings).

xatoo_’s picture

xatoo_ commented

I eventually choose not to use the Flexifield or Multigroup module but to create separate content types/nodes for the recurring data. (Although I use multigroup for another less complex situation and it works very nice.)

Since I have to be able to see trade units as ubercart products I had to make them separate nodes. The only downside of this approach is that users have to generate content multiple times:

1. Create article
2. Save article
3. Create tradeunit
4. Refer to previous created article
5. Save article and go back to step 3 as long as there are tradeunits to be added
6. Create pricing offer
7. Refer to previous created article
8. Save pricing offer and go back to step 6 as long as there are pricing offers to be added

Obviously this is bad UX compared to:

1. Create article
2. Fill in tradeunit data
3. If there are more tradeunits to be added, click 'Add another item' and go to step 2.
4. Fill in pricing offer
5. If there are more pricing offers to be added, click 'Add another item' and go to step 4.
6. Save article

It would be very nice if there would be some possibility to create nodes and auto-reference them during the creation of another node, using the AHAH response method multigroup and flexifield use. If somebody knows how to achieve this, please let me know.

WorldFallz’s picture

WorldFallz commented

There are several options for creating nodereferences-- just search the modules page with 'nodereference' and you should find the options.

leon kessler’s picture

leon kessler commented

s.toonen, I'm in a similar situation, and was wondering how you got on. Did you find a module or way to improve the ux (nodereference_field perhaps)? Would you have chosen to use flexifield/multigroup had you not required your "subnodes" to be ubercart products?

My scenario is that I have an office node type, and each office can have multiple activities. Each activity can then have multiple area's covered.

I looked into all 3 solutions:

Multigroup - would be my preferred choice as it's part of cck, but it does not support multiple fields, so I can't use these for the areas covered in an activity.

Flexfield - Seems like a suitable option, as it does allow for multiple fields. However, I'm not convinced it will do well in the structuring of content, the setup just doesn't seem that logical (a content type that is converted into a field). Also, it seems as though there are issues with the "add another" button for multiple input fields anyway (and on my first go with the module I got a nasty error trying this).

Node reference - Perhaps the long way round is the best? I'm testing out the nodereference_field module, which allows referenced nodes to be created and edited at the same time as the parent node. However, it like multigroup does not support multiple fields.

So there really doesn't seem to be any viable solution at this present time other than creating my own field in a custom module.

vacilando’s picture

vacilando commented

Another possibility is to create your own CCK compound field as explained in the great article at http://poplarware.com/articles/cck_field_module

Unfortunately, Views integration is missing even for that solution.

—
Vacilando services | blog @vacilandois