Currently it must use existing nid that must have content of type. What I would like to see is that we could dynamically get required webform nid and select from all available fields. It's a hit and miss game so if nid is false or field doesn't exists, it would return no results. I'm not sure if this is possible but this would allow building views for multiple webforms with different fields instead of building a view for every webform that uses views.

Comments

dshields’s picture

Dynamically selecting nids from some contextual or exposed filter would make this about a million times better.

quicksketch’s picture

Status: Active » Postponed

I don't think this is likely to happen. The UI challenges around "just use arbitrary fields" is complicated to manage. Even on a site with a small number of forms (20-50), you'd run into a huge problem of listing all the fields on all those different forms. Restricting by NID first solves the UI problems for the most part. The only way I could see supporting a "dynamic" NID is if there wasn't a UI at all beyond a textfield for component ID (or maybe form key).

So although I think it's unlikely that we'll add support for any kind of wildcard NID, I made a separate, more easily built feature (from the UI perspective) over in #2036805: Use default views instead of hard coded listing pages, where we'd introduce basically a Webform-specific super-field where you only need to add a single field for all components in the entire form. Then when viewing the view, you'd be able to add/remove any component from that webform on-the-fly. Perhaps it's not exactly what you're wanting, but from a UI perspective that's much more likely to happen.

dshields’s picture

My dream is that components or fields would be reusable across multiple Webforms, so submissions could be aggregated and compared. I think I'm dreaming too big.
EntityForm is likely a better solution for anyone looking for this type of functionality.

quicksketch’s picture

Issue summary: View changes
Status: Postponed » Closed (won't fix)

Moving to won't fix. In your situation, the need to reuse fields across a small number of forms is probably better suited to Entity Forms like you suggest.