Make views content panes available as display suite fields?

Cool, thanks for the feedback!
This is some information I can play with.

Making content available in display suite would be an issue for display suite. THe content is generic, so it could if it wanted but I think in that particular context it can only use field api fields and pseudo fields.

DS has an api to create fields via custom modules (which is different from the D7 core or D6 cck fields api).
It should be possible for views_content to hook into that API.
This code could live either in views_content or in ds. But definitely prefixed as views_content_*.

When or if my use case gets close to this, I might produce a patch. Either here, or on the DS side of things. We'll see.

Getting my hands on this task.
If you are interested in this, it would be nice if you could cover some of the views part of this, while I do the ds part.

I would prefer to see this in ctools views_content, but if you want it in ds instead, fine.

One way or another, I would appreciate your support to fill in the blanks for this patch :)
Probably just some views_get_view(), ->set_display() and ->execute() ?

--------

I wonder if it would make sense to restrict to specific bundles and view modes in the view configuration, so we don't crowd the field ui form.

Also, we should make this work for more than just "node", and "entity:node.nid".

This obviously "needs work", the patch is definitely not meant to be committed like this.

And, as mentioned, even if you think this should rather go into ds eventually, it would be nice if you could use this issue to help me iron out the views part.

I made this a custom module.
Both for proof-of-concept, and so I have something to use for my own projects.

The module creates one field per view, for those views that contain views_content displays.
Each display is a formatter.

As a result, one can never have two displays of the same view active in the same view mode.
I think that's an acceptable trade-off, considering that too many fields can make the ds configuration form quite unpleasant to work with.

-----

Now we need to decide, should this be a separate module, or shipped with ctools, or shipped with display suite?
You said this should rather be part of DS, but maybe you want to have a second look, now that a working module is available?

Nice!
For this specific situation I find #6 to be more convenient.. esp, since there will probably be many views displays to be added this way.
But still good to know.

I wonder, what about providing this as an "empty" row in the field UI form, similar to the one for adding field groups?

Hi,
maybe I am overextending this issue.
I hope something useful can come out of it nevertheless - be it a new feature or module, or just documentation.

I am trying to get this to work with Organic Groups. On a node/%node/something page, I want to show a list of group posts for this specific group.
It should be mentioned that those views that ship with og use the gid as an argument, not the group's nid / entity id. In D6 this used to be the same, in D7 it is separate - a group node of nid=555 might have a gid of 60.

With ctools page manager, I would create a variant of node/%/something, add a context relationship to get the gid, then use the default og views panes with their default argument setup.

Now trying the same with a ds dynamic field, it seems I can not add to the context. Instead, I
However, on ds (with a dynamic field), I can not add to the node context. It seems I have to use nid as the views pane argument.
(and that's the same for my custom module in #6)

Fine, so I add the relationship on the view instead. But which one?
OG views relationships are quite poorly named :( There is og group, og group membership, and other things that seem to be the same but sound different.

------

So, I guess, the names of og relationships is slightly outside the scope of this issue.

What fits in this issue:
- Can dynamic fields context be extended with relationships?
- If I continue with the approach from #6, how could I do it the most generic, allowing other arguments than just nid? (I guess I need to figure this out by myself)

As swentel mentioned above, DS dynamic fields can be used to add ctools content panes.
From my experiments, the context argument that is passed to those content panes is the node nid. The group gid is usually not available, and there is no way to extend the context with relationships - afaik.

That said, I managed to do what I need with my custom "views_content_ds" module, + content panes.
Up-to-date code can be seen here,
http://redmine.bewelcome.org/projects/bw-drupal/repository/revisions/dev...
and the feature
http://redmine.bewelcome.org/projects/bw-drupal/repository/revisions/dev...
This is all open-source, so that's ok to share.

Relevant modules are
views_content_ds
nodeaspect + pageapi
bw_groups
bw_forum (for custom formatters and ds fields)
bwf_groups (feature)

If that helps..

This does solve one half of the issue, but not the other half.
1) eva and other things are now available in panels (if I understand correctly).
2) any panel panes are available to display suite via dynamic fields.

Point (1) is fine.
Point (2) still feels inconvenient to me.

It would be preferable having those views displays available ds fields directly, not using some crazy dynamic fields configuration.

Both in D6 and D7, I have my own custom logic for this purpose. In D6, I have my own custom views display type. In D7, I use views_content. Both of this have performance benefits over views_attach / eva, because the view does only load and execute when it is actually needed.
Question is, should I continue to use this only for myself, or should I share it as a module, or should it be included in ctools or ds?

For the record:
I just released Views content DS for exactly this purpose.

For the EVA thing, there is some activity in this issue:
#1617030: Make EVA not be a preprocess field

update with status fixed and solutions

Closing the bullets