Code per Views

Agreed. How would you envision the interface? In other words, where on the Views UI would you imagine a CSS or JS field?

I'm not sure any module except Views add/modify any of the display options. (Correct me if I'm wrong.)

Display options are defined for each display plugin (i.e. the different "displays" you can add for a view like Page, Block, or Feed). The display plugin is defined as PHP class that includes an execute() function that renders the view and an options_summary() function that defines all the display options for the plugin.

To add "Code per View", both functions would need to be overriden, redefined, or somehow extended. I see any way of doing that. The page display plugin is defined as the views_plugin_display_page class in the Views module in the plugins/views_plugin_display_page.inc file.

To this included in the Views module might be inappropriate (nevermind the chance that the Views maintainers might not want to include it).

Currently, module developers can create new display plugins (among other plugins. So we could create a new "Page with Code" display plugin that would extend the Page display plugin to include a CSS and JS field that gets included when the view is rendered. The problem is that views rendered as something like a block or pane would not have these options -- only views being rendered as a "page with code" could.

Ideas?

Otay.. so I release a project to address this Code per Views issue by creating a views display extender plugin. You can find it at http://drupal.org/project/cpv.

If we want to merge Code per Views back into to CPN, perhaps a broader term for the project is appropriate (since views and views displays are not nodes).

Good work! I haven't looked at it closely yet, but it does make sense to merge them together. Though I don't have a good vision for what the new project should be called, I'd be happy to merge your Code per Views into a sub-module of Code per Node. I've been thinking that it would be good to create a sub-module called Code per Blocks and move all the Block-related stuff there, anyway. Perhaps it would be best to merge these for now, and then when D8 comes out, start a new project with a new name and architecture.

Thoughts?

This needs a patch before it can be marked 'needs review', but I agree that merging them together would be useful.

grammar

Bumping this to a 7.x-2.0 issue.