restrict fields returned via views.getView

I think that I originally tried to get it to work this way, but had trouble and just abandoned it to manually set on the flash side. Its probably time to revisit this.

Scott

Not currently core

Here is a patch that contains two modifications:

1. It corrects the behavior to return view-based stdObjects rather than node-based stdObjects. So any columns you see in your table view will be returned, and anything that you don't see won't be returned.

2. If you'd like to further limit the fields that are returned, you may do so by specifying them in the "fields" argument. If "fields" is empty, all fields will be returned.

Here is a revised patch that addresses http://drupal.org/node/255251, where it was pointed out that fields need to be rendered before they are sent. It uses the same methodology that the views_bonus CVS and DOC export modules use.

views.getView will return an associative array with 'headings' and 'rows', so that all required information for the view is available. Each row and the headings are keyed upon the queryname of the view field.

The arguments you pass to the service get forwarded on to the view. I tested this by adding a Node: ID argument to the view and passed in both single and multiple nodes separated by a "+" as arguments. I also tested restricting the fields to those specified and that works for me as well.

This patch was run against the May 8 version of the services module.

Great patch, heydere!

Did a small clean up:

• removed $fds[] = $field; as it's not used anywhere
• in $output['headings'][$field['queryname']] = $field['label'] ? $field['label'] : $all_fields[$field['fullname']]['name']; the last $field['fullname'] substituted for $field['id']

And a minor fix:
if (!$result) return services_error(t('Missing required view arguments.'));
I have a view argument set to return "page not found" if it's missing.
In this case views_build_view returns FALSE and the traversing of $result['items'] fails with an error message.

To my mind it's questionable if output fields themeing is a good thing in all cases..
For example, I have a cck field called 'price' with a suffix set to 'USD'. In UI it shows as '250 USD' and it's what expected. But the views.getView returns me '250 USD' too! And it's not so good in the case when I want to calculate the average price in flash client.. I do want raw data in this case.

Maybe we should expose an additional optional boolean argument 'theme_fields'? Or an array argument with a list of fields, that should be themed.

I have done some investigation (while trying to get view service work like I wanted):

Unfortunately your first patch doesn't do what it is intended to. 'items' mode is just the same as 'result' besides that you get an array of objects instead of mysql resource. The query is exactly the same and so the information you get. And it is definitely doesn't honor actual view's display settings. You will get node references as nids, you will get some fields you didn't asked at all (like 'changed') and, finally, you will miss some requested fields ('body' being the example).

It is because some info (like node's body) is extracted not by the query itself, but by the field handlers, which are called during 'themeing' process. So you can't get fields' values without themeing. And so it's hardly possible to provide 'theme only selected fields' option to views.getView method (which I suggested initially).

The bad thing is that Drupal doesn't separate 'themeing' and 'data modification' stages clearly. First is bad for services, because you want to control presentation. Second is needed obviously to make it possible for modules to modify (or add) content (think cck).

I ran into this kind of problem with cck and views. If you will try to display node's 'body' field then you will get the full node with body text and all the node's cck fields (if any) already rendered. You will not be able to get raw body text. See patches at http://drupal.org/node/160641.

Sorry about taking so long to get back to this. I really want it to be working in production mode, and hopefully we'll get it figured out soon.

You brought up two topics, the way that 'items' is used, and the way that fields are rendered:

1. I'll take another look at the way 'items' is used - I haven't had any problems yet so may have to ask for an example...

2. I definitely believe that we need to theme the fields in all cases. If you don't want to see the fields as "250 USD", for instance, you can change the way that view outputs the field itself. If you don't want to ruin that specific view for your regular users, you should be able to create another view with the display options you do want, and use that for your rpc call instead.

You can change the rendering options for each field in the view's edit page, under fields -> option. If your CCK field doesn't give you that rendering option, it is a deficiency that should be addressed at that level, rather than at the services level.

If we don't do it this way we're asking the services module to do things that the views module already takes care of for us.

As you said I had to make another view for use with services specially.

Guys,

Views 2 (available for D6) allow users to select several displays for each views. It will allow users to select with fields they want to use.

regards,

massa