Review Custom PHP-Based Styles in Views

Version of that patch minus the console.log() function calls :)

(never mind, that version sucks... improving on it now)

Here's a fixed patch, with a few formatting improvements.

Hey. I was thinking about this earlier today. I think this should should be a hook. The reason why is to be able to support an interface of choosing styles. It also might make sense to have a theme function in between. So, here's the workflow that I am thinking.

1) Get styles from a hook.
2) Through the settings form, users can choose which styles to use for features or other stylistic places.
3) Run styles through a theme function in case someone wants to override what a specific style is.

I guess my main goal is to provide a collection of styles, like GMap does with markers, but something a little more simpler to extend. It also leaves a lot of room to do things like have different styles based on content type or taxonomy terms.

The theme only method is good and looks like it will work, but does it is only overrides instead of building a collection of styles.

Let me know what you think?

--
zzolo

Here is what I imagine that goes along with how we have been doing our hooks. This is the hook_openlayers_styles_info().

/**
 * Implementation of hook_openlayers_styles_info
 */
function openlayers_styles_openlayers_styles_info() {
  // Basic info on where to get the actual styles.  Helps separate code.
  return array(
    'openlayers_styles' => array(
      'callback' => 'openlayers_styles_styles',
      'file' => drupal_get_path('module', 'openlayers_styles') . '/includes/openlayers_styles.styles.inc',
    ),
  );
}

Then this is the callback defined in the hook. There is not much reason to separate out each style into its own function, so we can just create a big array with options.

/**
 * Callback for styles hook
 */
function openlayers_styles_styles() {
  // Build actual styles here, as many as we want
  return array(
    'cool_steel' => array(
      'name' => t('Cool Steel'),
      'description' => t('What a stupid name.'),
      'style' =>  array(
        'pointRadius' => 5,
        'fillColor' => '#ffcc66',
        'strokeColor' => '#ff9933',
        'strokeWidth' => 4,
        'fillOpacity' => 0.5,
      ),
    ),
    'another_example' => array(
      'name' => t('Another One'),
      'description' => t('Etc...'),
      'style' =>  array(
        'pointRadius' => 20,
        'fillColor' => '#ffcc66',
        'strokeColor' => '#ff9933',
        'strokeWidth' => 1,
        'fillOpacity' => 1,
      ),
    ),
  );
}

The OpenLayers API module would provide a couple defaults, then we could make a more in depth openlayers_styles module, as this has been how we have been doing similar things.

Also, since this is a very visual aspect of the site, it might make sense to run this through a theme, so that themers can simply override some of the styles that are defined without creating a whole new module and implementing hooks. Basically, it just passes the collected array of styles to a theme and by default returns it. Here's how it would look when putting together the styles array:

$styles = theme('openlayers_styles', $styles);

This would all be represented in a new fieldset in the settings form. There would be a dropdown of all styles for "default", "select", and "temporary" (though we dont really use this one).

Let me know what you think. It seems like a little much, but will provide the most flexibility. Also, this does not really address icons as marker, which is a shame. We could do something similar with that as well.

Also, I had noted in the views plugin that we should remove the style php code option if this hook/theme layer was implemented, but it would be really helpful to have the php provide the style for an instance where the feature will have a variable radius based on other data.

Oh, and we could get fancy and make a map on the settings form have a feature that is updated with the style choices via some JS. This way people can actually see what a style looks like before saving.

@rsoden,

Thanks for the patch. It looks good. The only problem I have with it is the way it works in the Views part. The styles (and control) options should be in the Settings Form (meaning the OpenLayers settings form), and then it is just a matter of getting the form to work in the plugin settings. We should be able to just add specific settings for the Views in the plugin, and use the existing from to customize the map itself.

As for rules based styles: I think this is important, but the best thing to do is use the PHP textarea that is in there now, and just make it a little better (making these changes will help a lot). First off, almost all use of rules-based styles would be in Views (though it could integrate with lots of things). Second, creating an interface for a rules system can get pretty complicated. It would be awesome if we could leverage an existing module. Token comes to mind, with Token Rules. But, again, I would put this down as post 1.0.

I am going to work on getting this patch in and making some changes to it.

Commited: http://drupal.org/cvs?commit=226994

Feel free to test out. Changing name to address the views PHP views thingy.

So, I fixed some bugs last night that were not allowing the default styling to work.

I alos tested out the Variable Styling in the Views Plugin, which does seem to work. Though it should probably support the four different kinds of styles for each feature, not just the default (if it is possible).

Heres my example function to use some fields to manipulate radius and color. Its not efficient, but the idea is there.

<?php
function openlayers_variable_style($fields, $row) {
  // Make color array that maps an integer to a hex, determined by lightening a color from RGB
  $base_color = array(
    'R' => 56,
    'G' => 89,
    'B' => 100,
  );
  $color_convert = array();
  for ($i = 1; $i <= 10; $i++) {
    $temp_rgb = array(
      'R' => ($base_color['R'] < 255) ? $base_color['R'] * (1 + ($i * .09)) : $base_color['R'],
      'G' => ($base_color['G'] < 255) ? $base_color['G'] * (1 + ($i * .09)) : $base_color['G'],
      'B' => ($base_color['B'] < 255) ? $base_color['B'] * (1 + ($i * .09)) : $base_color['B'],
    );
    
    $color_convert[$i] = '#' . dechex($temp_rgb['R']) . dechex($temp_rgb['G']) . dechex($temp_rgb['B']);
  }
  
  // Make style array
  $style_data_2 = array(
    'pointRadius' => $row->node_data_field_random_color_field_random_color_value,
    'fillColor' => $color_convert[$row->node_data_field_random_color_field_random_color_value],
    'strokeColor' => $color_convert[$row->node_data_field_random_color_field_random_color_value],
    'strokeWidth' => (int) ($row->node_data_field_random_color_field_random_color_value / 2),
    'fillOpacity' => 0.5,
    'strokeOpacity' => 0.6,
  );
  
  return $style_data_2;
}
?>

And then the code to go in the Views Plugin would be:

<?php
return openlayers_variable_style($fields, $row);
?>

I have changed the variable styles to use a theme function now. So the options form for the View Plugin simply is a checkbox to enable whether or not to look for the theme. The only problem I might see with this is exporting/importing views. But since variable styles is a visual thing, it makes sense. So, here is an example:

<?php
function phptemplate_openlayers_views_feature_style($view, $row) {
  // Make color array
  $color_convert = array(
    1 => '#3366FF',
    2 => '#CC33FF',
    3 => '#B88A00',
    4 => '#F5B800',
    5 => '#CCFF33',
    6 => '#66FF33',
    7 => '#003DF5',
    8 => '#FF33CC',
    9 => '#6633FF',
    10 => '#3366FF',
  );
  
  // Make style array
  $style_data = array(
    'pointRadius' => $row->node_data_field_random_color_field_random_color_value,
    'fillColor' => $color_convert[$row->node_data_field_random_color_field_random_color_value],
    'strokeColor' => $color_convert[$row->node_data_field_random_color_field_random_color_value],
    'strokeWidth' => (int) ($row->node_data_field_random_color_field_random_color_value / 2),
    'fillOpacity' => 0.5,
    'strokeOpacity' => 0.6,
  );
  
  return $style_data;
}
?>

One could check the views name and display to change per view.

Seems to be working fine. Marking as fixed. Please re-open or start a ticket if you run into any bugs.