Allow Views export of all style settings

Thanks for reporting this issue. I consider this a bug though.

The suggested patch is not how I would solve this as invoking the form to extract the default values seems wrong.

We need to add a new hook for this I guess. What do you think?

/**
 * Implements hook_graphapi_default_settings().
 *
 * @return structured array()
 *
 * @see hook_graphapi_settings_form().
 */
function [engine]_graphapi_default_settings() {
}

One question regarding your patch is:

+++ b/views/plugins/views_plugin_style_graphapi.inc
@@ -50,6 +50,31 @@ class views_plugin_style_graphapi extends views_plugin_style {
+    if (isset($this->options['engine'])) {
+      $engine = $this->options['engine'];
+      $form_provider = $engine . '_graphapi_settings_form';
+      if (function_exists($form_provider)) {

Why only the selected engines settings? All default settings are needed when _configuring_ the display format. It is a little awkward though to have all settings available when _exporting_ the view I guess but I'm a little confused how views-export operates.

I pushed graphapi.api.php with the hooks including this new one. Feel free to patch the graphapi.api.php file ;)

I try to fix this new hook later this week.

What is the issue # for the jit? If none please create one ... as I need to apply that patch too.

This issue is still open. I just updated graphapi.api.php which links back to this issue.

Both @Itangalo and @clemens.tolboom plan to work on both thejit and graphapi the next (few) weeks.

The way I grasp option_definition

class views_plugin_style_graphapi extends views_plugin_style {
   function option_definition() {

is to provide placeholders for views to map it's value on. If one misses and named option the are not used. Thus we cannot drop possible settings as the choice of the engine is done through the settings in one go.

It is indeed not nice and even confusing when staging as on dev more engines could be enabled.

So on must disable unused engine before exporting / featurize :(

Patch looks good ... I try to apply friday

According to http://api.drupal.org/api/views/includes!base.inc/function/views_object%... we are not doing this ok.

We need to have

$options = array(
  'engine' => array(
    'default' => 'graph_phyz',
  ),
  'graph_phyz' => array(
    'contains' => array(
      'xyz' => array(
        'default' => 'pqr',
      ),
    ),
);

I'm working/testing this right now.

Steps I do:

1. http://drupal.d7/admin/structure/views/view/module_dependencies/edit
2. Edit and Save settings
3. http://drupal.d7/admin/structure/views/view/module_dependencies/export
4. Now search for the exported values to see only the display_options['style_options']['graph_phyz'] related values are arrays.

I committed the adjusted patch from #10 with the comments from #13

Pushed on master(!?!) : acff8ef..903b796

Thanks @Itangalo

Please tell me what your settings and steps are.

I exported the view manually so see all settings are in place as expected.

I think views think of defaults differently then we do right now.

Can you test by changing your global settings for spacetree then export. Or change a lot of settings for the view.

I've seen a lot of settings getting exported.

What we had was an array with values which is not views intention to export.

Btw .. I added to many ['contains'] as I want to add translatable later on.

I pushed #1528540: Make a demo page for all engines. so we maybe see better what's wrong.

I've fixed the global settings for height, width and background-color.
(commit hash: eb8d9a9..288d0bc)

I'll commit the same resolution for thejit modules but I'm still puzzling with those settings. Esp. why some settings are exported.

The way I see views defaults are indeed when values are missing. I guess that's a problem when staging a view where ie width is not exported. Maybe you could check the ctools / views / features issue queue for this.

@Itangalo: What is the export line for options when leaving out the 'contains'?

From #drupal-views @ irc : dawehner suggest not to use values when generating the form. Let views handle that.

(modified to shorten)
ClemensTolboom: I'm using views_plugin_style::option_definition() with 'contains' … is that option still the right thing to use?
ClemensTolboom: @see http://drupalcode.org/project/graphapi.git/blob/refs/heads/master:/graph...
dawehner: ClemensTolboom: what is $value here?
dawehner: ClemensTolboom: is the the actual option values or the option definition
ClemensTolboom: dawehner: a non-array value or an array with key=>value
ClemensTolboom: like from http://drupalcode.org/project/graphapi.git/blob/refs/heads/master:/graph...
ClemensTolboom: Maybe the wrong code is http://drupalcode.org/project/graphapi.git/blob/refs/heads/master:/views...
ClemensTolboom: or the form building does not match on de options … hmmm … I should check that first
dawehner: ClemensTolboom: from my standpoint graphapi_settings_to_views converts some option-values to views-options
dawehner: so no option-definition, because this seems to be done already by graphapi_graphapi_default_settings
ClemensTolboom: dawehner: should I leave out the values when rendering the options_form? http://drupalcode.org/project/graphapi.git/blob/refs/heads/master:/views...
dawehner: ClemensTolboom: i would say yes. on the actual form you probably always want to use $this->options
ClemensTolboom: So this is wrong http://drupalcode.org/project/graphapi.git/blob/refs/heads/master:/graph...
ClemensTolboom: I'll try to leave out values settings when generating the form.
ClemensTolboom: dawehner: tnx

This does not solve the why aren't the other values exported right?

Yeah ... that does not look like a normal export. At least to me. Ie diff.module will have a hard time and other parts of the export don't contain array structures.

One would expect similar structure for similar data. These outputs

$handler->display->display_options['style_options']['mapping']['to']['uri'] = 'uid';
$handler->display->display_options['style_options']['thejit_spacetree'] = array(
  'duration' => '250',
...
$handler->display->display_options['style_options']['graphapi']['width'] = '690';

are not similar. I'm not sure what's wrong but ie width is now exported ok.

My guess now is the options maybe misaligned when export is checking for the values somehow so export only sees default values thus does not export? I'll try to debug the export code tomorrow as I noticed the option_definition is called a zillion times when generating an export which is bad too.

I'm progressing a little. Debugging function option_definition() into views_plugin_style then into base.inc I found:

- Booleans are treated differently.

We do have a lot of booleans which are treated as number but should be defined with

array(
  'default' => TRUE,
  'bool' => TRUE
);

- our defaults are not views defaults

Our defaults for graph_phyz / thejit_* are configurable by the site builders so are strickly no defaults.

Zapping all defaults to NULL leads to exporting more settings. But this still misses the booleans.

function _graphapi_settings_to_views($value, $nullify_value = FALSE) {
  if (!is_array($value)) {
    if ($nullify_value) {
      $result = array('default' => NULL);
    }
    else {
      $result = array('default' => $value);
    }
  }

I'll try to refactor graph_phyz to fit this scheme using boolean first.

I've created two views patches:

(views) #1532986: base.inc views_object:option_definition() documentation is outdated.
(views) #1532216: option_definition is called oh so many times

to learn we can add a special handler when exporting to dump all values. I'm not in favor of doing this but it is as simple as calling views_var_export($var, $prefix)

Each engine must have default values in _code_, These values can then be used when configuring engine settings using views.

Changing the global settings for an engine should not be used for the defaults when using views.

I'm trying to fix graph_phyz first then see what's best.

This needs to get fixed. Period :-/

We have two commits done in the past

commit 288d0bc5c631d2fb3065612075fbafe1cd70c3b0
Author: Clemens Tolboom <clemens@build2be.com>
Date:   Wed Apr 11 19:15:27 2012 +0200

    Issue #1513198 by Itangalo: Fixed Allow Views export of all style settings.

commit 903b796b37ad2a176c0323028b4341cd000b12f4
Author: Clemens Tolboom <clemens@build2be.com>
Date:   Fri Apr 6 16:39:20 2012 +0200

    Issue #1513198 by Itangalo: Fixed Allow Views export of all style settings.

Hmmm ... I don't get it anymore.

Building a view part of the export contains engine specific values like

$handler->display->display_options['style_options']['engine'] = 'thejit_forcedirected';
$handler->display->display_options['style_options']['thejit_spacetree']['selected_node'] = '';
$handler->display->display_options['style_options']['graphapi']['width'] = '1024';
$handler->display->display_options['style_options']['graphapi']['height'] = '800';
$handler->display->display_options['style_options']['graphviz']['type'] = 'graph';
$handler->display->display_options['style_options']['graphviz']['output'] = 'png';
$handler->display->display_options['style_options']['graphviz']['graph']['damping'] = '0.99';
$handler->display->display_options['style_options']['graphviz']['cluster']['area'] = '1';
$handler->display->display_options['style_options']['graphviz']['cluster']['style'] = 'solid';
$handler->display->display_options['style_options']['graphviz']['node']['area'] = '1';
$handler->display->display_options['style_options']['graphviz']['node']['style'] = 'solid';
$handler->display->display_options['style_options']['graphviz']['edge']['style'] = 'solid';
$handler->display->display_options['style_options']['graph_phyz']['showLinks'] = TRUE;
$handler->display->display_options['style_options']['graph_phyz']['rankType'] = '0';
$handler->display->display_options['style_options']['graph_phyz']['rankDepth'] = '2';
$handler->display->display_options['style_options']['graph_phyz']['initScale'] = '2';
$handler->display->display_options['style_options']['thejit_forcedirected']['level_distance'] = '150';

So graph_phyz seems doing well. But thejit is not.

I need some user feedback. This issue has 5 followers.

Please help fixing this if still applicable.

Add please add a

<h3>Steps to reproduce</h3>

to the issue summary ... I'm kinda derailed with this issue :-/