New export syntax: allow export by tag, export to stdout, function header

Hey, started checking our your module. I suggest consolidating commands for this. Perhaps supporting a --tag flag with an implicit assuming of --name.

For example,

$ drush views export --tag=my_module

Where as the following are equivalent

$ drush views export my_view
$ drush views export --name=my_view

Would keep the name space cleaner :)

I plan to implement, reusing but refactoring this code (btw, thanks fajerstarter for a nice idea and implementation), two different commands:

$ drush views export
$ drush views dump

The former would create files like the original design, the latter would output to STDOUT in the format this patch uses (including the <?php header and so on).

Ideally, both would accept similar options, so we would have:

$ drush views export --tag=default
$ drush views dump --tag=default

There is some ongoing work in the dev version (where drush views tag is disabled since it will be exposed through these commands) , and I will post here once it's done. But I welcome feedback, or, why not, patches in this direction.

I know 'ls' detects whether it is printing to STDOUT or is piped to a file, so you maybe able to do a similar thing and leverage it and avoid expanding the name space. I suppose that is a very unixy solution.

@pescetti your plan to allow exporting to stdout or a file, with an optional --tag argument for either case, makes sense to me. i would personally suggest defaulting to printing to stdout, with another optional argument --output or maybe --path which specifies a filename, in which case output would go there.

you could also use two command names, export and dump, to indicate whether or not to print the "function default_views_default_views()" header. i would add another optional argument to use a different function name, too.

if you think that sounds like a good approach, i would sit down and write this now, although fajerstarter's comment above makes me think you've actually written some code and committed it someplace -- i don't see any updates at http://drupalcode.org/viewvc/drupal/contributions/modules/drush_views/ in the past 9 months, though. if you like my ideas, i'll get started!

I'm generalizing this issue so it better fits the ongoing discussion: let's use it to decide the new module syntax.

Comments received so far expose the following needs:

• Possibility to select by tag the views that must be exported
• Possibility to export (dump) to stdout, as one stream instead of the current approach to create different views.
• Possibility to customize the export and include a header so that the export (dump) can be reused as default views include file (for a certain module)

There are two points not to forget:

• The export/import cycle must be possible with all variants of the export functionality
• I would avoid breaking the current syntax (besides the needed small adjustments for commands containing spaces); for usability reasons, I prefer "import" to be the counterpart of "export"; so, replying to comment #6 by fajerstarter, I would still prefer "dump" for the continuous-stream export to stdout, based on these reasons.

A starting point to discuss the new syntax follows.

$ drush views-export [--target-path=TARGET_PATH] [--tag=TAG1,TAG2...] [view1,view2...]

This exports views as single files in the specified directory (if --target-path is omitted, a default path is used).
The views to be exported can be specified by a tag (or a list of tags) or by name: if neither is specified, all views are exported; otherwise, all views having one of the listed tags or names are exported.

$ drush views-dump [--module=MODULE] [--target-path=TARGET_PATH] [--tag=TAG1,TAG2...] [view1,view2...]

Shares the same syntax as drush views export but exports views as a stream to stdout. No options are provided to generate a file, standard output redirection will be used.
An extra option is provided for drush views dump, i.e., --module. I'm not sure about the name. The idea is that this function will generate the code (basically, the short header with proper function name) for the MODULE.views_default.inc file contents, so the call would be:

drush views-dump --module=my_module [arguments] > my_module.views_default.inc

The import command would be mostly unchanged, and be the counterpart of export.

For symmetry, we would need a restore command that is the counterpart of dump but unless someone sees a practical use case for it I think it's redundant: import in this case is done by enabling the relevant module.

I welcome everybody's comments on this draft: I'd like to see consensus on the new syntax before I (or we!) proceed with the implementation.

That draft sounds great to me, especially the ability to set the name of the module, although I assume you meant:

drush views dump --module=my_module [arguments] > my_module.views_default.inc

I'm not that picky about the syntax personally, as long as the functionality is present.

I would be very happy to help with this, for example by testing if you're already planning to go ahead and write this.

Development branch 3.x-dev started and this issue better fits there. I made minimal changes to the specification to match the Drush 3.x syntax and fix the typo spotted by mvc.

Tracking.

Re: #10, I can see the value of having all the views in one file, but I'm not sure it fits all situations. I'd prefer the option to export them as individual include files (with PHP header and so forth).

I export my views entirely for the purpose of keeping them in version control, and in this circumstance it's desirable to have one include per view so that I can version each view individually (as described in #671062: Closing the Circle: How to use drush views export for something that hook_views_default_views() can use). If anything, my views are specific to a particular site, not a particular module; the module I use to include them is just a catch-all.

In either situation, I'd recommend appending a line with // $Id$ after the opening PHP tag so that the generated view file is friendly to the the d.o packaging script.

+1 to xjm's comment in #14. Please see the other issue's patch for code that works well for this use case.

Subscribe.

For starter, maybe we can at least print the output to STDOUT. This actually my initial expectation when testing this module. Then anyone can use their own favorite unix tools to do the further work. For example, I can do drush views-export | append_php.sh > views_export_someviewname.inc since I prefer to have my views in a separate include files rather than one big my_module.views_default.inc.

+1 on #17 - subscribing

Thanks, this functionality is now committed to the 3.x branch, with a more general syntax than the one outlined here.

You will use something like:

drush vwex --tag=og,atrium --output=bulk --module=modulename

to produce a bulk export on STDOUT containing all views tagged "og" or "atrium"; the exported code will define a function named modulename_views_default_views().