Available entities browser

Subscribing. Would love to have this implemented as a submodule in the latest dev. Pretty please ;)

subscribing

Subbing

#1113654: Relation reboot has a relation browser built in. That do?

Hrm. What would stop the overlay getting really large too?

I am keen to get something like this working for a possible field UI based relation creator, but I'm a bit worried that we'd basically be re-creating the searchQuery interface... The problem is that you have to be able to find suitable entities across all available entity types and bundles, and entities are currently very unstandardised...

I thought EntityFieldQuery was made for that? Or couldn't it be done using efq_views? Other browsers e.g. for images (imagebrowser, nrembrowser, node reference browser, ...) use the "old" Views to retrieve such lists.

What would stop the overlay getting really large too?

&

Well I assume we could have a pager within an overlay.

...or have some sort of filters applied based on entity type/name/whatever other criteria (apache solr/faceted search style perhaps)? That would limit returned objects, wouldn't it? If the list is still too large perhaps also autocomplete search fields?

I would like to see Views used, no matter the container. The rendering of the selection for a relation should be as flexible as the relation construct itself. A View would let the developer implement VBO/filters/etc to create a relation browser in any format they desire?

Additionally, a Views JSON callback that sends the current state of other fields on the entity as context. Let the View take the contexts in as needed to provide the appropriate list of selections. e.g., depending on the content types/vocabularies involved and the state of the form, the developer can provide the appropriate relations available.

EntityFieldQuery only queries across one entity type, ok that's not very hard to deal with - just loop across available entity types, but I think that means views is out of the question, doesn't it? Unless you have one such view for each entity_type, perhaps.

The real problem is going to be limiting entities. There seem to me little point in in just displaying a view of all suitable entities. What if you have 4000 entities, and the one you're looking for is somewhere in the middle? With nodes, this might be easy, just do an EFQ and limit by: title contains user-supplied string (auto-complete style). But in general, entities don't necessarily have even a label. Eg. How are we supposed to find files?

Ideally by filename, MIME type, subdirectory, and node information where the file is attached to.

I can see that this is hard to do, though. It would need some kind of sophisticated faceted search interface. This is probably better off in a seperate project.

Right, none of that is possible to do with relation without specifying different processes for each entity type, which I really want to avoid.

I actually mis-spoke, file entities do have a label, but users don't - and neither will any entity that doesn't declare 'label' in the 'entity keys' array in hook_entity_info().

In response to #13:

http://drupal.org/project/efq_views does query across all entity types. Take a look at this image: http://drupal.org/files/images/base.png and you can see the option.

So this would be a good foundation to build an Entity Browser with Views and efq_views.

This would also allow people to build custom Browsers (by plugging in their own View) to better suit their own needs.

Subscribing... looks awesome!

@davidseth: yes, but it only does one entity type at a time.

As I said before though, we can loop over them. Here's a proof of concept. Apply patch, clear menu cache, then go to relation/autocomplete/entities/%predicate/%string where %predicate is a relation type you have created, and %string is part of the label to search appropriate entities for.

this doesn't work, partly because entity labels are not necessarily table columns - so we can't search them.

...ping? Status update please?

Hrm.. Probably we'll focus on #1175386: Provide widgets for specific entity types first, and come back to this if we can find a way to generalise it.

Thanx for taking the time to update the status Ned.

...heading there.

Ok, there is a generic entity autocomplete in the relation_add block, and there is a contrib module that does similar things as a field widget: https://drupal.org/project/relation_select

This is as far as we are going in terms of UI in relation core at the moment. If something comes up in contrib, we may consider merging it in, after a lot of good reports and testing. But we may equally remove more UI elements from relation, and make it a more API only module.

ok, setting back to NW merely because this information is something that Relation users should be aware of. Please copy-paste your previous comment with the link to relation_select at least in the project's front page (perhaps also in the module's documentation & this issue's summary). Thanx in advance.

This is now on the project page.