Loving the generated modules in bulk export, and this patch has added a useful part: #469456: Add info file to views bulk export

Could it be extended to include dependencies of modules required by the view, e.g. depending on selected styles and handlers?

I'll give you an example - I exported a view which required views_bonus_export (style of one of the displays was XML File), views_customfield (one of my fields) and CCK (handlers used in relationships, sort and fields). The Bulk Export .info file looks like this:

; $Id: views_export.module,v 1.6 2009/06/02 19:36:25 merlinofchaos Exp $

name = foo Export Module
description = Exports some views of foo
dependencies[] = views
core = 6.x

Ideally it would look like this:

; $Id: views_export.module,v 1.6 2009/06/02 19:36:25 merlinofchaos Exp $

name = foo Export Module
description = Exports some views of foo
dependencies[] = views
dependencies[] = cck
dependencies[] = views_bonus_export
dependencies[] = views_customfield
core = 6.x

I don't know how difficult this would be to achieve, but it would truly idiot-proof the code generator. =)

CommentFileSizeAuthor
#3 views-657292-export_dependenices.patch1.46 KBdawehner

Comments

dawehner’s picture

dawehner
Primary language German
commented
Version: 7.x-3.x-dev » 6.x-3.x-dev

I think you should have a look at the feature module. With the feature module you can export views, and i guess it will detect the modules automatically. I'm not sure, whether views should do it.

greg.harvey’s picture

greg.harvey
Primary language English
Location Occitanie, France
commented

Hi,

Agreed, Features module is cool for that sort of thing, but I'm not looking at it from *my* perspective. I'm a Drupal developer, I can use Features.

But it seems to me the use case for this Bulk Export feature is to allow people with little or no module development experience to quickly encapsulate their views in a module. Otherwise why is it there at all? These people will never use Features. So I thought it might be useful to list all the dependencies, if possible, as these same people might not be equipped to easily fix things if the dependencies are wrong and they try to use the module elsewhere.

I guess what I'm saying is, IMHO you either improve this tool or remove it and recommend people use Features (take away the attempt at idiot-proof exporting and accept it's too much work for too little gain).

Hope that makes sense. =)

dawehner’s picture

dawehner
Primary language German
commented
Status: Active » Needs review
StatusFileSize
new views-657292-export_dependenices.patch1.46 KB

The patch was easy :)
I guess it can be applied to 2.x, too

dagmar’s picture

dagmar
Primary language Spanish
Location Argentina
commented

I have a questions for this patch. If you have a view with 3 columns provided by the cck module, and a filter, provided by, let say Casetracker module. This patch will add only this two dependencies?

IMO this is going to add more dependencies than needed, isn't?

dawehner’s picture

dawehner
Primary language German
commented
Status: Needs review » Needs work

Oh yes, sure.

greg.harvey’s picture

greg.harvey
Primary language English
Location Occitanie, France
commented

Wow, it was obviously easier than I thought it would be! Thanks for doing that so quickly. =)

Regarding #4, I don't think I understand. Why would it be adding more dependencies than needed? If there are fields from CCK and a filter from Casetracker then they *are* dependencies, aren't they? I don't understand how this is more than needed? Maybe I'm missing something, but if the exported view won't function without them...? =/

dagmar’s picture

dagmar
Primary language Spanish
Location Argentina
commented

@greg.harvey take a look at the definition of hook_views_default_views()

/**
 * This hook allows modules to provide their own views which can either be used
 * as-is or as a "starter" for users to build from.
 *
 * This hook should be placed in MODULENAME.views_default.inc and it will be
 * auto-loaded. This must either be in the same directory as the .module file
 * or in a subdirectory named 'includes'.
 *
 * The $view->disabled boolean flag indicates whether the View should be
 * enabled or disabled by default.
 *
 * @return
 *   An associative array containing the structures of views, as generated from
 *   the Export tab, keyed by the view name. A best practice is to go through
 *   and add t() to all title and label strings, with the exception of menu
 *   strings.
 */
function hook_views_default_views() { }

This means that patch #3 only will fetch all installed modules that provides their own views.

What we have to do is go througth all fields, filters, arguments, relathionships, sorts, etc for a given view and see if they need an special module work.

I think we should implement a function like views_features_export

greg.harvey’s picture

greg.harvey
Primary language English
Location Occitanie, France
commented

I understand. Didn't actually look at the patch, which would've helped! I kind of assumed it would do what you describe, but I guess that's a lot more complex. It probably needs to though.

esmerel’s picture

esmerel commented
Status: Needs work » Postponed
merlinofchaos’s picture

merlinofchaos commented
Status: Postponed » Closed (won't fix)

Views Bulk Export is removed in D7,so we probably won't be changing it in D6. In D7, CTools' export.inc would need to be modified to allow dependencies, which it currently doesn't do.