Views export into separate files

Not for the 1.0 release. I'd like to see experimentation with this kind of scanning/inclusion work its way into Views and CTools export API before we dive into custom solutions in Features.

I second this.

I see the mass export of views into one file as a major short coming of features. Exporting then to seprate files would be a great step forward.

+1

Robeano asked me about this today because I had mentioned I was working on it last week. This patch is just a start. I'd like feedback on the approach I'm taking. I've only implemented it in features.ctools.inc so far.

Things that will need to be addressed yet:

-UI
If there is a UI, what's the level of granularity? Do you select that all Views are exported to separate files but not permissions to separate files? Or do you select on a View by View basis which are separate? Right now I've just a variable_get() where some better control would go.

-Override detection
This patch seems to break it. I'm not sure why yet.

-Files in separate folders
I think that'd be necessary as a feature could grow to dozens or hundreds of files. That'll require more patching of features.export.inc

Here's an updated patch that puts the new files into separate directories.

Interesting. There are some coding standards issues to consider. I probably would just call the directory "includes" instead of "features_includes".

I think it might be worth documenting the separate files option as advised during development only. Yes, it's easier to read one at a time, but it's simply better performance to have them all in one file.

I would rather see this built into ctools exportables directly if something like this is desired, then to deal with it one off in Features. Not to mention the performance implications (however small) are not worth it in my mind.

Thanks for the feedback febbraro. I too would like it if CTools had a way of automatically addressing this. I should have cross referenced an issue I created in April #1115966: Separating export files

The approach kenorb outlines in #1 is one that I used on projects before Features was released for Drupal 6 and I think many other developers use this approach when not using Features. Though it is not ideal, I think this is the way CTools deals with this space in practice.

I also don't think this is specific to CTools. I recently worked on a site with multiple Search API indexes. Exportables like these coming from Entity API could benefit from separation just as much as those from CTools. I started with CTools in the patch because it is the most common use case.

The performance impact of this approach is largely mitigated by the caching of the exportables.

The main benefit of this functionality for me is easier version control. In a feature with multiple large views worked on by multiple developers it becomes difficult to track changes.

It may be possible to accommodate this workflow in a separate Features submodule. I'll investigate this possibility. Would you be open to adding hooks that might be necessary? For instance a hook_features_api_alter(). Such a hook could also be used to alleviate performance bugs like #1153028: menu_links_features_export_options() dies with too many items.

I might be open to adding hooks to allow it, if you work something up post it here and we can evaluate it.

The change being discussed towards the end of #1317054: Provide support for exporting of altering of components is especially relevant.

Thanks for the heads-up on that new change Grayside. I've started a sandbox that so far matches the functionality of the patch in #6. http://drupal.org/sandbox/stevector/1392162