Support entity-based Views handlers

No, you didn't miss anything, this really is currently unsupported. One easy way around this (at least I hope it's easy — never worked with Views row style / display plugins before) would be to provide an "Entity view" row style that would simply use the entity_view() function and offer the available view modes for configuration (if there is more than one).
At the moment I have very little time, though, and a massive (and growing) heap of feature requests, so this might take a while. If you're familiar with Views row style plugins, maybe you want to try a patch? I would of course help with information, and would be glad to have this additional feature in the Search API.

The efq_views provide such a row style.

Sadly this isn't part of views, because views doesn't use entity_api.

There are thoughts, though, to move some features from the efq_views module into the Entity API — this would also allow me to use them.
But in any case I could also just copy the handler from efq_views — so, thanks for the tip!

How about this?

Patch generally looks good. I wonder though whether we should implement the handler generically in the entity API instead though, so e.g. it could be used in regular views to show profile2 too.

The question is whether there is a generic way for the handler to retrieve the entity type + id, which works with any base table. Maybe we can come up with a good convention for that - any ideas?

I tested the patch with profile2 (via search api) and got quite some notices ala

# Notice: Undefined index: 1 in _field_invoke_multiple() (line 309 of ...../modules/field/field.attach.inc).
# Notice: Undefined index: 1 in _field_invoke_multiple() (line 309 of ...../modules/field/field.attach.inc).
# Notice: Undefined index: 1 in _field_invoke_multiple() (line 309 of ...../modules/field/field.attach.inc).
# Notice: Undefined index: 1 in _field_invoke_multiple() (line 309 of ...../modules/field/field.attach.inc).
# Notice: Undefined index: 1 in _field_invoke_multiple() (line 309 of ...../modules/field/field.attach.inc).

However, I doubt the cause in this patch. I'll have a closer look later.

The question is whether there is a generic way for the handler to retrieve the entity type + id, which works with any base table. Maybe we can come up with a good convention for that - any ideas?

Having this in the Entity API would of course be great, I'm all for that! Even though this would probably require some hook_views_data_alter()ing to include my base tables as fitting for the display.
As for a convention, I'd suggest letting modules pass the loaded entity directly, as it happens now in my handler. This allows the query class to do one single entity_load(), instead of one for each row, and also maybe other processing. As the $result handed to the render() method apparently is an array (or is it just in my case?), passing the entity in $result['entity'] might make the most sense. Largely, of course, I argument like this because it would only require a minimal change on my part — but I might be right nonetheless. ;)

OK, just had a look, $result is not always an array: in efq_views, it's the entity itself, directly. However, as this robs a great deal of flexibility, I'd still suggest wrapping it into an array.

Also, I do hope those notices are really unrelated to this issue, or the Search API in general. Holding back the commit until this is resolved.

had a closer look at it, and the problem was a wrong call to entity_view()

updated patch attached, which works fine for me. However, we should pass all entities at once for viewing in order to benefit from the performance improvements.

Then, I think we should have a look at #1077148: add an entity-view row plugin.

Thanks, but you forgot to actually attach the patch. ;) (Set back to "needs review", please, when you do.)

Passing all entities at once would of course be a good idea, but I don't know how this could be done. Views apparently doesn't offer this option, the row style plugin only gets one result at a time.
Ah, hm, probably this would then be a style plugin, not a row style … Won't be necessary here, though, if you plan to incorporate this into the Entity API soon, anyways. Thanks for linking the issue there!

ops, here it is (-p1)

@style-plugin: I think with pre_render() it should be possible to do it in the row-plugin.

again patch from #9 generated with -p0

As mentioned in #1077148: add an entity-view row plugin, this should probably just be abandoned in favor of the Entity API solution.
And since you based your solution there on the code here, your patch was not in vain either way. ;)

Just committed a patch that integrates with the current suggestion for the Entity API. (Since it isn't at all dependent and adds only additional information that is ignored at the moment, this is possible without problems.)
If the solution that will eventually be committed will remain compatible, our work here is done; otherwise, this will have to be revisited.