Closed (works as designed)
Project:
Services Views
Version:
7.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
24 May 2011 at 15:42 UTC
Updated:
26 Aug 2015 at 03:20 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
dragonwize commentedWhat exactly is the path you are using?
Services 3.x does not use the views.retrieve syntax. Instead it is [endpoint]/[resource]/[id]/[action]. For the views resource you use "views" or your resource alias.
Comment #2
g10 commentedNoticed the same issue (with 7.x-1.x-dev, using AMFserver)
The problem is not the syntax, when the same syntax for node.retrieve is used, it works fine, but not for views.retrieve.
Difference is, in the access callback method, that node.retrieve checks if the $args[0] is a string and makes it an object, views.retrieve expects a named array (eg. $args['view_name'] but receives $args[0] as a string).
I'm not sure where the exact issue is situated, is this a server issue? (as the comment in _node_resource_access mentions: ' // Make sure we have an object or this all fails, some servers can mess up the types.)
I noticed node_resource normalizes the arguments as an array with an object for each entry, thus followed this:
$args[0]->view_name opposed to $args['view_name'] which is expected in the callback, whilst the callback receives $args[0] with a string value
This solves the issue, the callback receives the proper arguments, and returns the view…
patch in attachment.
Comment #3
g10 commentedfixed a typo/but in last patch where the optional $display_id is not passed
Comment #4
g10 commentedPrevious patch is unnecessary!
traced the issue to the amfserver module, which did not pass an associative array to the views resource
solution is here:
http://drupal.org/node/1218070
Comment #5
josebc commentedThis is happening with SOAP Server also
Comment #6
kylebrowning commented