I am coding a widget that needs views support. I used the hook_field_settings callback with $op == 'tables', which gets called in 

./content_views.inc:19:    $result = module_invoke($module, 'field_settings', 'tables', $field);

If the op returns a views tables object, it gets processed, sort of: enough so that you can tell it sees your fields. But I'm having enough trouble getting it to fully work that I'm not convinced it does :-)

If the op is not implemented, content.module supplies its own default implementation, which seems to work pretty well. So given that:

  1. The default does a great job, and does some magic that's hard to do in your own implementation, and
  2. AFAIK, no one is using the 'tables' op. At least, I can't find any examples.

Is there any reason for the 'tables' op to keep living? Especially since the default implementation is pretty good.

Comments

yched’s picture

yched commented
Status: Active » Closed (won't fix)

date module needs to provide its own views tables, I think.
You can read http://drupal.org/node/117621 for more insight on why the views tables were made overridable.

Anyway, since the default tables provided by CCK fit your needs, where is the problem ?
I think the doc in field.php makes it clear that the 'tables' op is optionnal, and should be implemented only if you find you have specific needs that do not get addressed by the default stuff.

Torenware’s picture

Torenware commented

yched,

First, thanks for pointing out field.php to me; I was unaware that the hooks are documented there.

I'm still looking for an example of a working 'tables' implementation. KarenS, it turns out, did not use the op in pollfield.module: she implements hook_views_table directly. I'm not sure why she chose to do this in the end, but it might be interesting to know why she did.

The one thing that the default support makes a bit difficult is options. I need to be able to allow the user to specify a string, since the usual Default/etc. handlers are not dynamic for my particular application.

yched’s picture

yched commented

KarenS, it turns out, did not use the op in pollfield.module: she implements hook_views_table directly
I think it was because the hook did not exist when she wrote the module.

You can provide your own 'tables' using the hook, and use content_views_field_tables() to get the default CCK tables and modify / build on it. See fields.php

Torenware’s picture

Torenware commented

yched --

on second thought, maybe the default handler doesn't work so well.

I did some testing with cck_address and cck_fullname. Neither display correctly with the default handler. These modules, like mine, have multiple pieces of data per field, and make use of the 'database columns' option on hook_field_settings. I'm not totally sure links works right either.

At a minimum, there's a documentation issue here, because there are a fair number of widget modules that do not support Views correctly, at least in its table view. I'm going to report bugs on the relevant modules, but it would be good if one of you folks investigated this a bit. It definitely does not work as cck is currently documented.

yched’s picture

yched commented

Yes, CCK's default views tables only exposes fields for the first column ('main column') of the field.
It has been sufficient for quite a long time, but with more 'advanced' field modules out there, it starts to show its limits.
See http://drupal.org/node/131953 for a discussion about that.