I love the new markup options that are available in 7.x-3.x, and that Views generally allows and helps themers to do whatever they want to a given piece of output. However, I've really been struggling with Views lately, to the point where I actually dread working with them entirely. Here's why:

  • The default format and field settings are hardly ever what I want. I realize there are good reasons for the way things currently stand, such as having to support an upgrade path and also trying to appeal to the masses. This is no big deal when working on a site that has only a few views, but when there are many, it becomes really, really tedious to click, click, click to apply the same settings over and over again.
  • A lot of the time, a developer creates the views, puts them in Features and then they come to me to theme. Unfortunately, I end up spending more time doing things like modifying the format, re-ordering the fields, configuring the markup settings to remove markup and labels and then, dealing with exporting it and putting it in version control than I do actually writing CSS or markup for it.

Some of us discussed this today on Google+ and initially thought we could use hook_form_alter, but @bangpound explained the problem to me earlier today that there's no way to re-write the defaults right now:

Once you get to hook_form_alter, the handler's default options are not distinguishable from the options the user has deliberately chosen. What we need is to be able to alter the values returned by a handler's option_definition() method. When a Views object is instantiated, the base class's construct() method calls set_default_options(). This loads the defaults from option_definition() (where the markup settings for fields and labels are stored).

To handle this effectively, you'd have to alter the returned values array to include the whole type hierarchy, because the options we are concerned with are part of views_handler_field class, but they will always be instantiated as a subclass of this. Fortunately, drupal_alter takes an array. If we can get the class inheritance hierarchy (each prefixed with "views_options_definition_") for the current handler into an array, we'd call drupal_alter($types, $defintions). Then implementing hook_views_options_definition_views_handler_field_alter(&$definitions) would let us change the markup settings for fields before they're created.

This points to a larger problem with Views field handlers... they output markup and they cannot be overridden. (They can be, but it would be an incredible task. Hacking Views would be more reasonable at that point.) I can swap plugins, displays, styles, etc., but to be able to use a get a particular field or column or whatever from a database table, I have to use the handler which cannot be overridden in any reasonable way.

I'm not proposing that we make changes to the defaults, but I think it would be really great to be able to configure the default settings for the field handler options, so that there can be less clicking and pain involved for all.

Is this something that could be considered?

CommentFileSizeAuthor
#10 1244576.patch416 bytesdawehner
#2 alter_option_definition-1244576-2.patch792 bytesAnonymous (not verified)
#1 alter_option_definition.patch0 bytesAnonymous (not verified)
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Anonymous’s picture

Status: Active » Needs review
FileSize
0 bytes

This patch is a first attempt. I am well aware that this greatly increases the functions called for each handler, and this cost is paid over and over again.

This patch allows me to use this function to change the default style settings on fields:

function MODULE_option_definition_views_handler_field_alter(&$definition) {
  $definition['element_type']['default'] = '0';
  $definition['element_class']['default'] = '';

  $definition['element_label_type']['default'] = '0';
  $definition['element_label_class']['default'] = '';

  $definition['element_wrapper_type']['default'] = '0';
  $definition['element_wrapper_class']['default'] = '';

  $definition['element_default_classes']['default'] = FALSE;
}
Anonymous’s picture

Hmm. patch didn't attach.

Jacine’s picture

Status: Needs review » Closed (won't fix)

I guess this is a wont fix. Thanks for trying @bangpound.

Michelle’s picture

Don't be too hasty... I read the G+ convo and a couple things 1) if he did actually mute the post, he may not have seen all the follow ups and 2) he said something on IRC about going to LA and not being around much so might not have even seen this issue yet.

Michelle

dawehner’s picture

Status: Closed (won't fix) » Needs review

Personally i don't get why this issue is closed.
Let's mark it back to old status.

Afaik earl is in disney land at the moment.

Jacine’s picture

Oh, well I closed it because I took this comment to mean that it wasn't possible/feasible: "Also wrong about the defaults. They are used every time the view is loaded and altering them would be very problematic and screw up exports."

Maybe I misunderstood. I just don't want to piss anyone off further by asking for this.

dawehner’s picture

yes that's true that alterting the defaults would currently probably break a lot of different views.

But it might be possible to somehow have an thing on the top to be able to do it.
So basically it would be altering on the form default level, so it wouldn't refer with existing ones.

Jacine’s picture

Thanks @dereine. That would be awesome. :)

edward_or’s picture

This is something I have also been struggling with. This is not a problem that is unique to views but due to the incredibly flexibility views offeres it is something that comes up again and again. The ability to detect in some way whether a value has been set by a user or is a default of the module is a problem themers have whenever a module gives users the ability to set the type of markup that will be output.

It would be great if people involved in themeing could set what they consider to be sensible defaults and have these changed only if the user has set something different.

All by way of saying off that something like this "...would be awesome. :)"

dawehner’s picture

Status: Needs review » Needs work
FileSize
416 bytes

Here is a patch of what i talked about, but this certainly needs some work.

rudiedirkx’s picture

Issue summary: View changes

Why does it need work? Seems perfect to me. And the fastest option. Implementers can check the class name, handler type etc etc and alter when those are what they want. No need for an array of alter options.

rudiedirkx’s picture

Status: Needs work » Fixed

This has been around since

commit 72951a2a56f43e9d19454ffe65986c19796a79da
Author: Daniel Wehner <daniel.wehner@erdfisch.de>
Date:   Wed Sep 28 00:49:38 2011 +0200

intentional or not =)

What I was actually looking for is a way to alter a handler's option_definition(), to add custom options to the handler config. That doesn't seem possible. Storing my custom config in a display extender is way too hard.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.