Document: how is this different from other node-link related projects

Hi,

This module seems to be very interesting.

I hope it to help me build "composite-fields" i.e. a field made of several different fields with different field-types.

I will try asap.

Thank you

Like CwDrup I found this module looking for a "composite-fields" solution too. Combining a nodereference field with another (e.g. a simple text field) can disclose new opportunities to a better use of nodes (sometimes I have to use nodes for such relations).

nodereference module by itself (the one included in CCK) doesn't let you create the node you're about to reference as part of the editing of the node on which you have a nodereference field. Modules like addnode and subform solve this, but both of them are only on Drupal 5 currently, whereas flexifield is only on Drupal 6.

Other than the Drupal version compatibility difference, the big architectural difference as I see it is that flexifield doesn't create a separate node for each item and then reference it. Instead, it stores all the data (as a serialized structure) with the field. If you delete the node with the flexifield node on it, all its data is deleted, you don't have orphaned nodes.

On the one hand, you lose a lot of flexibility by not having each item its own node. If you're modeling a situation where each item really needs to have its own kind of independent existence, then modules like nodereference, addnode and subform are a better way of handling that situation. On the other hand, for a use case like the one described on http://drupal.org/node/292059#comment-955449, it doesn't really make much sense for each item to be its own node, what you really want is for each item to be a regular field item, but not be constrained to being of a single, module-defined type. For those situations, I believe flexifield will be better (once it's more stable and better documented).

Updating this issue to reflect the need for documentation