Provide widgets for specific entity types

This would be very nice. I think it might be useful to provide a sort of relation_field_provider_info hook so custom entities can define their relevant select options function, autocomplete callback function and not have to worry about building FAPI elements.

chx: Why do we need specific widgets per entity_type? Sorry, you've probably told me this before, I'm obviously having trouble accepting it or something :/ maybe I'll get it if you write it down somewhere where I can come back to it...

It'll still be a dummy field, since we're not gonna be storing data.

Wesnick: I reckon that's stage two. Might need to wait a bit on that one.

Because there is no guaranteed way to get a label, and there may be better ways to display information about each entity type.

The entity_label method is also horribly inefficient.

Per-entity sounds great. Although Relation should provide core entity support.

so if i'm not mistaken, a widget can't be used on node creation only node editing ? because you need the nid to create a relation ?

i tried using the relation_create function in hook_entity_insert so i have access to the nid, but i noticed that hook_entity_insert get's called twice because relation_create is calling it as well .....?

Can't you just check that the entity being inserted is a relation? Except then you write off the possibility of creating relations-on-relations during relation creation. Not sure how much that matter, at least for now..

Actually no: the second time it get's called $type or $entity->type isn't even availabe...
so if i check if $type is set - and then check which type it is,i'm still getting an error that the second argument for hook_insert_entity isn't passed the second time it gets called...

the relation does get created though, with the error....

isn't there a better way to do this, or maybe i'm missing something..?

try !isset($entity->relation_type). ->type is a node-specific thing.

thanx, but the main problem is that the $type argument isn't passed one the second call of hook_entity_insert...
'Warning: Missing argument 2'...

relation.module #444 -- this is in the relation_save function
--> module_invoke_all('entity_insert', $relation);

this one gets executed right after my hook_entity_save where i've put the relation_create function. and relation_save gets called in relation_create.

using releation_create in the hook_entity_insert causes hook_entity_insert to get called again.
so you see, checking on $type or anything like that is useless, the error keeps popping up.

so i figured that maybe there's a more proper way to create a relation on node creation, because obviously this isn't how it's supposed to be...?

please update to the latest dev, or preferably, to git, as it makes development work far easier. Relation_save is no-longer called from within relation_create - you have to call

$relation = relation_create($relation_type, $endpoints);
$rid = relation_save($relation);

Dunno if that'll fix the problem though..

updated to the new dev and tried it with your code suggestion... same problem with the double call and argument missing the second time. Gonna take a look at it later to check if i can workaround it.

ok, so here's what i did to fix my problem:

in relation.module #518

changed

module_invoke_all('entity_insert', $relation); 

to

module_invoke('relation','entity_insert', $relation);

same with the entity_update..

i don't get the errors anymore, but i was wondering if this can have a negative consequence later on ?

adjustments as a patch..

please ignore the patch as we want other module to hook into the relation_save. naught101 submitted a patch so there's an extra argument passed, and the error doesn't occur anymore.

> so if i'm not mistaken, a widget can't be used on node creation only node editing ? because you need the nid to create a relation ?

That's surely not the case. Look at how image_attach used to work on D6 -- that created a relation between the current node and an existing image node, and worked during node creation.

> Because there is no guaranteed way to get a label, and there may be better ways to display information about each entity type.

Doesn't the admin creating the relation field supply the label?

@Joachim: "Doesn't the admin creating the relation field supply the label?"
We're talking about the label for the entities in the autocomplete here, eg. node title, user name, what ever. Some entities (like relations) don't have any label (relation types have a label, but relations themselves don't). You're correct on the other point, as long as the relation creation happens in hook_entity_insert().

Regarding labels, IIRC entity module has a system for getting labels out of entities.

Relation is not dependant on entityAPI, and we don't want it to be, if we can avoid it. Anyway, for relations, and other entities like it, the only "label" that ANY method will be able to extract is the numerical ID, simply because no other label exists. I think an autocomplete for entities like this would be more than a bit useless.

> I think an autocomplete for entities like this would be more than a bit useless.

Not just autocomplete then -- also select lists and checkboxes.
Which means that this module can't be a successor to nodereference.

What are the reasons against depending on EntityAPI?

checkboxes? Joachim: you're missing the point. Some entities DO NOT HAVE LABELS. What would you have next to the checkbox? a number?

We would prefer not to depend on any contrib modules.

The way I see it is this: if this module is intended to be the successor to nodereference and userreference then it needs to provide the ease of use those had. That means checkboxes, select lists, and autocomplete. This is simply a given. If on the other hand it's more an API module, then that's fine too. But then we should probably let http://drupal.org/project/references know to change their project page text.

I'm scratching my head thinking of entities without labels, and just ran a module_invoke_all('entity_info'); to have a look.

I also don't see what is so bad about depending on contrib modules.

if labels are defined for other entity types somehow, relation entities can have labels too - implode the labels of the endpoints with a dash.

I'd thought about that too, but then what happens if you have a relation between two relations (eg. something like "happened at the same time as"), or a relation between two entities that have numeric labels?

> relation entities can have labels too - implode the labels of the endpoints with a dash

Aaah, now I get it. Relation entities don't have labels :D

But I think if a site admin wants to have relations between relations, they should expect things to get complex. Maybe require/allow them to add a label field to the relation type?

btw: related to #6: #1042822: Developers need an $entity->entity_type property

Short discussion regarding widgets: https://gist.github.com/1079482

Hopefully this can be realized quickly.

Would love to follow the short discussion but this pastebin link is not working.

Try again.

<letharion> chx: Do you already have any thoughts on whether and how to provide a references-style field widget for nodes?
<chx> letharion: no
<chx> letharion: we will reuse the references widgets instead.
<letharion> chx: Great. Have you talked to the maintainers? Do we intend to copy their widgets into the relation codebase?
<chx> copy?
<chx> heaven forbid
<chx> this is field API
<chx> we just need to make a field type
<chx> and then alter widget info to get em in the house.
<letharion> chx: I'm not sure I follow, will references then depend on relation?
<chx> if you install references then we will reuse 'em widgets
<letharion> chx: Ok, so the widgets will not reside in the relation module. So what I could do to advance this, is to patch references to use relation as a backend?
<chx> letharion: if you want to enhance this.....
<chx> letharion: you need to write two field types based on relation
<chx> letharion: one, a directional field where r_index 1 is node:*
<chx> letharion: and then you need to implement hook_field_load, hook_field_update (will be interesting), hook_field_insert
<chx> letharion: and finally hook_field_widget_alter
<chx> letharion: makes sense?
<letharion> chx: Yes, I think so :)
<chx> oh and hook_field_storage_pre_insert
<chx> which unlike the above is a real hook
<chx> but therein you can set up fields to be skipped
<chx> which you need to
<chx> same field_storage_pre_update
<letharion> I have implemented a field previously, but I don't know what all those hooks do. I will read about them and see if I have further questions.
<chx> letharion: but first, i do not see Rules committed.
<chx> letharion: this combination will hopefully let you take over from the default storage

@chx ; References widgets rely on [node|user]_reference_potential_references(), which in turns rely on specific $field['settings'] properties. Using those widgets for a 'noderef-like but relation-backed' field type *might* work if the 'noderef_based_on_relation' field type replicates the settings of the noderef field type, but that could get a bit ugly...

Maybe some re-engeneering / abstraction of the References widgets could help (let the field type provide a custom 'potential references' callback), but starting new widgets from scratch sounds like it would be less intricated down the road...

(counts as a 'subscribe')

If I'm not tracking the implications of the part of this discussion concerning labels, let me know.

Would these labels be translatable so that multi-language sites can use the local language equivalent and still be choosing the proper end-points and relations? Do any of the options discussed in this issue automatically provide this capability, or would it have to be added explicitly by the Relation module or the developer who uses the Relation module?

Also, as others have asked, why the reticence to use the Entity contrib module, which seems to be one of those modules whose intention appears to be filling in basic missing functionality in the Entity API with basic CRUD capability? If the Entity and Relation modules were both moved into core, would it then address the dependency concern?

...subscribing.

First thanks everyone for all the awesome work!

@chx
I found that the latest code you submitted (97b1955) you added an instance settings to the field that allows selection of relation_type. When using this I noticed that the field formatter didn't respect this. The attached patch fixes this.

Also I tried to use the but nothing I seemed to type in came up with anything.

This is something I considered before: I think it would make sense to have a field-level setting that allows you to either blacklist or whitelist relation types that can be included in the dummy_field. Then the widget will only appear on entities that are included in one of those relations, and same for the formatter. But that's probably a separate issue. But I don't really see why there would be a reason to restrict relation types on a field instance level, nor why there would be different options for formatter and widget.

FWIW : defining scope at the field level, so that all shared instances have the same predictable set of possible values, is more inline with the way 'reference' fields (or fields with allowed values) generally work.
OTOH, this is generally useful for views integration (being able to present relevant options for filter, args, relationships...). Maybe this is less true for Relation's specific views integration ?

Back to the not entirely resolved question about labels, assuming that relations are the only entities without labels as implied above, surely you can capture everything with a format [source endpoint][directional relation type label][target endpoint]

(adding in 'and's and additional endpoints where needed for multiple arity).

Example:

Relation type 'letting agent' ('is agent to', 'agent is'): Node: agent ->- Relation: renting appartment
Relation type 'account supervisor' ('supervises', 'supervised by'): Node: manager->- Relation: letting agent

• first relation (node ->- 'rents' ->- node):

Source label: Johnson family
Target label: 100 First Street
Relation label (for admin): Johnson family rents 100 First Street

• second relation (node ->- 'is agent to' ->- relation type 'rents'):

Source label: Dave Meadows
Target label: Johnson family rents 100 First Street
Relation label (for admin): Dave Meadows is letting agent to Johnson family rents 100 First Street

• third relation (node ->- 'supervises' ->- relation type 'is letting agent to'):

Source label: Bill Riley
Target label: Dave Meadows is agent to Johnson family rents 100 First Street
Relation label (for admin): Bill Riley supervises Dave Meadows is letting agent to Johnson family rents 100 First Street

It's not good grammar and it's a complicated label, sure. You'd only display this on the admin pages. But look at it: it describes a relation on a relation on a relation. It's a complex, abstract entity to understand, yet any user can understand exactly what it represents and how it's structured just from glancing at the label.

"What's that? Bill Riley is no longer overseeing Dave's work on the Johnson family account in 100 First Street? Okay, I'll delete the relation... where is it... there it is, that's the one to delete. Done. Easy."

The only point at which this breaks is if you somehow get a loop, where it's possible for there to be a chain of relations all of which relate to relations, and this then loops back on itself. But that's not possible - a loop would require a relation to have an endpoint that didn't exist when the relation was created.

subscribe

Relations do kind of already have label: just "Relation ###", where ### is the rid. But that's not enough, the label also has to be stored in the DB for entityfieldQuery to be able to read it.

But the point wasn't that relations don't have labels, it was that for ANY entity type, there is no guarantee that it will have a label in the DB, or that if they do, that there'll be a way to know what table/column it's stored in.

--- post edited after a bit more research --------------------

entity_get_info() names the table in ['base_table']. Label is slightly trickier, ['entity_keys']['label'] finds it if it's defined. For what to do when it's not defined, I'm looking at entity_label(), label callback in hook_entity_info(), and also how Entity Reference and also Entity Reference Field do this in their widgets.

It looks like the best way is to use entity_label() where possible with two tiers of fallback:
1) For the small number of entities with no labels we want to cover for (user already has a label callback on username, so that would be relation, maybe one or two more), a few fixes for generating specific entities using either hook_entity_info_alter() label callback or a case switch
2) For everything else, some standard formula based on mandatory keys. Most likely just entity label plus a lookup on the column named in the mandatory ['entity_keys']['id'] to create something equivalent to 'Relation [rid]' - not great, but these aren't common and represent pretty niche use cases for relations (Redirect is the only one I've found so far).

You can't search over entity_label(). You need a database column.

Of course, for user, the name column in the database is the label, so we can create a special case for that (I don't know why it's not in 'entity keys' in user_entity_info() though..).

crossreferencing: #1061688: Available entities browser

wasn't naught101 working on an embeddable block which provides the possibility to add a relation from the current entity ? i haven't looked into the details, but maybe it could be a starting point for a proper widget ?

http://drupal.org/sandbox/naught101/1275426

Nothing embeddable about that block. The form could probably be used by the widget though.

Partly in order to get some good ideas about future UIs, it'd be good to get people's hopes and dreams for relations over here: #1282376: Brainstorm: What do you want out of relation?

Hi -

I've been developing a relation field widget for my current project - http://drupal.org/project/relation_select. It acts as a drop down list & uses EFQ Views & exposed filters to select the entities. It's a work in progress so any feedback would be welcome.

Cheers,

Ben

Thanx for letting us know Ben. I'm heading there now and hopefully will be able to provide feedback soon.

After a bit of discussion with chx, we've removed the widget. This is basically because it was pretty broken, and difficult to deal with. After seeing Ben's relation widget (in #49) we realised that the best path to take here would be to see what contrib can come up with (this is an API module, after all, UI is just a bonus). If someone comes up with a good solution that mimics a field widget, we'll consider merging it in to relation core.

So, closing this for now. In the mean time, you have two block-based UIs, (one that mimics a widget), and Ben's widget. If a new widget comes up that is looking really good, feel free to open a new issue to discuss putting it in relation core.

oh, and the kill commit was 232dc32, if anyone wants to take the old code and run with it in contrib.

Cheers
ned

Hey chx -

Glad I could help! Thank you for writing such a great module to build upon - it's completely changed the way we're building sites.

Cheers,

Ben

This issue needs an issue summary, so that people coming here know what was finally decided and why. I tried to do it, but I cannot fully grasp most of what was debated.

Ben's Relation Select project and #1282376: Brainstorm: What do you want out of relation? as well as any related articles/issues/projects should be mentioned there so that people know where to head to.

More details, including link, about Relation Select.

Thanx ned! That was fast ;)

Just a thought which I don't have the time to follow through, but how about using a widget based on Hierarchical Select when there are multiple entity types?

Ie:

[type dropdown] [entity name dropdown]

The way it works is that the content of the 2nd dropdown are only fetched once the first dropdown has been chosen, at which point you'd have a single entity query.

Worth trying, although anything with a contrib dependency is less likely to get in to relation core.

Probable a very horrible solution, but in my usecase it works.

Adding a 'label callback' in the hook_entity_info and this callback:

<?php
/**
 * Implements hook_entity_info_alter().
 */
function CLIENT_entity_info_alter(&$entity_info) {
  $entity_info['relation']['label callback'] = 'CLIENT_relation_label';
}

/**
 * Gets a relation's label.
 */
function CLIENT_relation_label($relation) {
  if ($endpoint = end($relation->endpoints[LANGUAGE_NONE])) {
    $node = node_load($endpoint['entity_id']);
    return $node->title;
  }
  return 'Relation ' . $relation->rid;
}
?>

Could you create a patch for this?

Updated issue summary.

Auto Complete widget for relation.
https://drupal.org/sandbox/vordude/1814752