D7

I've been thinking about this for the last few hours and how something like this might work in Drupal 7. As you may know the way nodes and fields work has changed dramatically, and it would be unwise to simply port the Drupal 5 version over.

The minimum amount of work a field reference should do is to reference the entire field that is chosen from the current entity. In that case the reference would simply show the field's title, or in the case of the autocomplete: Field title [field_name].

Of course, most people will want to be able to do more than that.

A full key for a field's value in the database (once you know whether which field you want, and whether you want the current revision or a specific revision - more on THAT later) is:

• entity_type
• deleted
• entity_id
• revision_id
• language
• delta

I think we can safely ignore 'deleted' and assume the user would never want to reference a deleted field, as the results would be unpredictable in that the field would change whether garbage collection had been performed. The 'revision_id' attribute is only useful when getting a field from a specific revision.

The database also provides 'bundle' but I don't see the use in that in the field itself, as if you target a specific entity_type and entity_id you wouldn't need to store the bundle value. But the 'bundle' thing could be useful for a setting where you can pick which bundles contain referenceable fields. Though being able to just pick from a list of 'referenceable fields' seems a lot easier to cope with than having an option for 'referenceable fields' AND 'referenceable bundles' - and then do you also have 'referenceable entity types'?.

Ideally we would be able to store all those different keys I listed as separate columns in the field's db table, so as to open the door to useful views integration. But in the form, the keys for the values will still have to be one of those awkward strings that concatenates a bunch of things together. Hopefully this could one day be solved by using more advanced form widgets using jquery and hidden fields, but noone seems to have come up with a surefire drupal module for this yet.
So the key would be something like this:

<field name>:<delta> <entity type>:<entity id>:<revision id> <language>

e.g:
field_name:0 node:32:32 en

So in the autocomplete you'd show something like this:
My field (value 1) - The node title (22/08/2011 - 14:18 by bob) EN [field_name:0 node:32:32 en]
Pretty awkward, but I don't see that we have too much choice.

For current revision:

My field (value 1) - The node title (current revision) EN [field_name:0 node:32:curr en]

And replace 'curr' with NULL in the database storage.

If revisions weren't allowed in settings it would be even simpler:

My field (value 1) - The node title EN [field_name:0 node:32 en]

Similarly if the reference was for the entire field, not a specific delta:

My field - The node title EN [field_name node:32 en]

Current language:

My field - The node title (current language) [field_name node:32 curr]

Or language not allowed in settings:

My field - The node title [field_name node:32]

That last one would actually be the most common use-case I bet.

Another consideration to make is perhaps to allow showing the value of the referenceable field in the display value of the list of options. Not sure how well this would work in various cases, but it could still be an option.

One thing I don't have my head around yet is how to use Views to restrict references options, especially given that a fields come from multiple entity types but views handles only one entity type, so perhaps using multiple views, or maybe theres another *type* of view that would solve this dilemma nicely.

I'm going to have a tinker with node_reference and see if I can determine how to implement this.

Actually instead of distinguishing between current stuff and not allowed in settings stuff, they should just both use the simpler output.

Just thinking about how part of the settings form would look like:

Entities:
(*) Current entity
( ) Existing entities
( ) Both

Revisions:
(*) Current revision
( ) Specific revisions
( ) Both

Languages:
(*) Current language
( ) Specific languages
( ) Both

Values:
(*) All values
( ) Specific values
( ) Both

And if you pick the 2nd or 3rd option in each setting, more settings may come up to restrict the referenceable fields up-front based on that property.

These functions would be used to display the field.
http://api.drupal.org/api/drupal/modules--field--field.module/function/f...
http://api.drupal.org/api/drupal/modules--field--field.module/function/f...
http://api.drupal.org/api/drupal/modules--field--field.module/function/f...

I need to work out what sort of options there are for displaying the field in different ways, in order to come up with the display formatters.

Looks like the formatter output could work the same as in Drupal 5 where it either does the 'full', 'teaser' or uses the same mode of the referring node, or a default field view.

wow, it seems comments are handled as fields so this might also work as an alternative to http://drupal.org/project/commentreference
not sure how obvious it will be to identify the comment you want though, lol

I had a little tinker with it, looks like the hard part is going to be getting the list for the options/autocomplete, so if I can figure that out this could work.

I've got the queries half working, looks like the only remaining problem is how to use autocomplete to filter by the field label, or field name, and just general other autocomplete usability issues given the added complexity of targeting the fields.
That plus filtering the nodes/entities that come up based on a View... that is gonna be a lot harder than other reference modules.

I have created a new project so I can properly work on this module.
http://drupal.org/project/field_reference