Use EntityReference as a generic reference field

I just found http://drupal.org/project/ref_field

I'm trying to get a sense of what the future is for references/relation too because I maintain View reference and Block reference, and a lot of the implementation code is the same, and I'm also really keen to see a Field reference module being actively maintained again, because one of my modules (Peekaboo) sort of does a half-arse field reference to provide functionality that really should be done by a fully-fledged Field reference module - and I think with the support of this project something like that could happen again if the implementation relied on references, as it would reduce the maintenance load for the modules overall.
These object (views, blocks, fields) aren't handled by entity controllers, so the abstraction wouldn't be perfect.

http://drupal.org/project/entityreference

Good discussion on the future of an entity reference field over the entityreference queue, maybe the saner approach is having relation module handle everything ? see this comment. So once that simple field is ready, there can be migrations from the current different options (specially references, but also entityreference and ref_field) to relation.

The http://drupal.org/project/ref_field now says on the project page that people should use http://drupal.org/project/entityreference. So I think that and http://drupal.org/project/relations are the logical alternatives.

http://drupal.org/project/entityreference is missing the ability to use a view to create the selection list and it has no equivalent for nodereference_url. And it may introduce a dependency on EntityAPI (which is already required if you use Organic Groups or Drupal Commerce or several other popular modules). If those things were fixed we might be able to use that rather than duplicate all this functionality.

Just to clarify, I don't think a dependency on Entity API is something that has to be 'fixed', that was just a comment.

missing the ability to use a view to create the selection list

There's an open issue for this, that's the last remaining thing that needs to be done.

may introduce a dependency on EntityAPI

I think the idea is to have the code depending on Entity API in a separate (optional) submodule, though I personally have nothing against depending on it.

So focusing the efforts there seems like a good idea. With the module already having wrappers for fixing core entity access, reverse relationships, and other goodies, would be a shame to reinvent that elsewhere.
Changing this to a support request and marking as "fixed" so that it remains visible in the queue for a while longer.

Actually, let's make this a feature request. Once all the pieces are in place there we could refactor the code around it.

If http://drupal.org/project/entityreference had the ability use use Views and we created an upgrade path from References to Entity Reference, we might be able to totally deprecate this module in favor of that one. When it comes to duplication of code, the most generic implementation wins :)

Here's a breakdown of the differences I could discover in a half hour or so when trying to figure out which of these modules to put into Using Drupal. :)

Usage stats

References: 20K, Entity Reference: 1200

Advantage: References

Dependencies

References module is self-contained. Node Reference and User Reference modules rely on the References module, included with the package.

Entity Reference requires EntityAPI and CTools.

Advantage: References

Field/widget types

References module provides two new field types: User reference and Node reference, with widget types of Autocomplete text field, Select list, and and Checkboxes/radio buttons.

Entity Reference provides a single "Entity reference" field type, with the same widgets as References but the addition of an "Autocomplete (Tags style)" widget. So you can either select a single value, or comma-separated values.

Advantage: Entity Reference

Field settings

Node/User ref both display different options depending on the type. You can limit by node type for node reference fields, or role/user status for user reference fields.

Entity reference asks you to choose the target type, and target bundle. So if target type is "node", it shows you target bundle values of "Article, "Basic Page", etc. However, for "user" there are no options to filter the list by role/status.

Advantage: References

Views integration

Both modules seem feature-equivalent in terms of basic views integration and providing fields, filters, sort criteria, etc. based on their field values.

Where References wins out is by providing the ability to populate the list of allowed node/user references from a View using the "References" display style.

Advantage: References

So, I think we're going to go with References module, but put a pointer to Entity reference as a hot "up and comer" so that people reading 1-2 years from now aren't stuck. Please feel free to correct any of this if it's wrong.

Hey webchick ... I wouldn't say so straight forward that "no dependencies" is better than having them. That way you'd be punishing re-usability and modularity and favoring code duplication and monolithic design, just to cite some.

If more context is given (such as "we want this in core sometime") maybe the fact can be grounded but I guess that just plain saying that could even foster some not-so-correct thinking in some ppl. Don't you agree ?

Little off topic but thought of putting it out :)

cheers

For the purpose of one of the intro chapters in a book written for people trying to figure out Drupal for the first time, lack of external dependencies definitely lands in the plus column for me. ;) But for others more seasoned with Drupal site building, I agree it's not a huge deal, and Entity Reference certainly isn't the first nor the last module to depend on CTools and Entity API. The write-up in #10 was specifically about Using Drupal though, I just figured it might be helpful to others so I posted it here too.

Nice write up webchick. You have summaries my thoughts on the matter perfectly.

Side note, we have never used a user reference that has not been filtered by role. This feature does not exist in Entity reference.

My only issue with References module is the project page:

References will most probably be deprecated in the near future in favor of Entity Reference, which should probably be considered first on fresh D7 projects.

With over 10% of all Drupal 7 sites using this module, it appears to be going nowhere for the time being.

While the extensibility of Entity references is great (albeit tightly coupled OO and at risk of falling over at the slightest API change), the KISS approach of References has a lot of appeal.

Without the project page message, I'm 70% in favor of References, but I am currently sitting uncomfortably on the Entity reference side of the fence with a foot caught in the railing looking at the changes that have destroyed the custom widgets on the site and wondering if the grass is really greener on the other side still.

This module has no future. Use Entity Reference or try to figure out wtf Relation does.

I have contributed to References and maintain several modules that integrate with it, but KarenS is on the money with the 'generic' comment. I don't agree with webchick's assessment, but it was over 6 months ago so I'm not going to deconstruct it.

This module has no future.

This is the main obvious upgrade path of potentially 200,000 Drupal 6 users. So for these folks, I hope that there is a future even if it is a static path with no new features on the horizon. :)

Relations, the concept is cool, but complete overkill for 95% use cases and would be almost impossible to teach a client how to set these up. And from memory, if you set up a n-n or 1-n and you delete a single end-point, you kill the relationship, also making it less than useful in many use-cases, although this may have changed since I last looked at it.

btw, shouldn't this thread be marked as "won't fix" as per the current maintenance status?

The project page already says that this module will be deprecated in favor of EntityReference. It is probably used in too many places to actually remove the module, but it's not really being maintained and no new features.

References works. You can use it. But I recommend switching to EntityReference where possible.