Creating multiple view displays of the same type

I've attempted to modify the view component to respect a display_id, but I haven't got it to a working state yet. This is definitely one of the big issues that's keeping anyone on my team from consistently using patterns, and that's preventing me from advocating patterns to others.

(One of the things that I'm having a really hard time with is the XML-inspired data structures that are processed by the components. It would be so much easier to understand what was going on if the YAML/XML/PHP was parsed to a simple, concise structure.)

Hi, vaish. Sorry that I didn't see your response until now - unfortunately, I don't recall the particulars of the issue I was facing. I'm pretty sure that I attempted to best match my input to the form_values, but with the views ui it's very hard to know which forms are actually being submitted, and the output from patterns (last form submitted) didn't seem to point me in the right direction.

The views export syntax makes my skin crawl. Actually, even calling it a syntax makes my skin crawl. :) Maybe I'll write a wrapper that takes a nice, human-readable format and then creates the appropriate objects for the views importer. Working with views seems a common enough (and complex enough) case to be worth a customized implementation (rather than using the forms API).

Ok, now I mostly remember what I was trying to do. I wanted to have displays with, for instance, names "block_1" and "block_2". It seems like line 177 of views.inc requires the name to be the same as the display plugin ($check->display_plugin == $match['key']). Possibly, name and display_plugin are used interchangeably, while they should be distinct? (It's quite possible I'm not following this correctly.) If that's the case, I would consider solving this by adding an optional value to set the display_plugin, defaulting to the display name if not supplied.

Hi, @vaish. I know how views export works, but my attraction to Patterns is to simplify and streamline initial configuration. I really don't want to do a bunch of configuration in the UI and then dump a vast amount of nasty-looking code into a multiline string in YAML. :) Also, importing a view can only work if you drop the existing view first, which means you've got to keep the entire view setup in a single hard-to-maintain (because of the views export syntax) pattern. Icky!

When I say "The views export syntax makes my skin crawl" I mean that I want my patterns to use a syntax that I can edit by hand. My use case is that I want a human-readable set of patterns that I can quickly edit to create a new site. The views export syntax is pretty opaque, and it's full of explicit settings that should be made implicit through the use of defaults (which is one of the fantastic side-effects of using the Forms API).

I'm working on debugging the module - I'll let you know if I get something that seems like a solution.

Hi, @vaish. I ended up totally rewriting the views component. The FAPI code was just way too complex to meaningfully troubleshoot, let alone maintain, and it seemed like a better architectural approach to just use the simple, well-documented api for view objects (that is, pretty much the syntax that comes out of the views exporter). The big difference between this and the views_ui import syntax is that we can still use existing patterns (even though there's a clearer syntax that's supported by the new views.inc) and it updates existing views/displays without breaking a sweat.

Now, I'm not sure if I'm covering all the necessary view use cases, and I think it would be a good plan to write a test suite for coverage of all the implementations we want to support. I think a more complete set of example patterns would be useful both for encouraging developer adoption and for use in test coverage.

I'm attaching my replacement views.inc, with no guarantees that it works in the current patterns - I've been making other changes to fix gaps in support (forms with their submit handler on a button rather than the form can now be run in patterns, drush patterns work as expected, disabling modules no longer wrecks your install, etc.) but I haven't been rolling patches for these things individually. At least views.inc is self-contained!