This patch (which isn't really a patch, because it adds a new service and lots of Views2 integration) is an alternate, more-fully-featured interface to Views2.

It adds five new options as Views style plugins:

  1. A "Services Feed" display type (just like "Page" or "Feed")
  2. 2) A "Services" style type
  3. 3) Three row style plugins:
    • Services Raw - Returning raw DB fields
    • Services Fields - Returning styled fields
    • Services Nodes - Looking for a 'nid' row and doing a services_node_load() on each row.

The new views2.get service works just like view.get, except that it accept an alternate optional display_id parameter. If you do not specify display_id, it will try to find the first "Services Feed" display attached to the view.

This code still needs more testing and error checking, as well as support for things like the fields argument, but I think it'll be a nicer way to work with Views2 going forward.

Services | flash.icanhaslayout.com

The new service returning results from a view built with the Services Fields row style plugin.

Let me know what you think!

Comments

Pleae re-roll as a patch - http://drupal.org/patch/create

Amitaibu, this consists of only new files. How should I create the patch? Neither cvs diff nor diff want to create it.

diff -urpN old new> your_patch.patch

the N adds new files.

Status:Active» Needs review
StatusFileSize
new18.52 KB

Thanks much for the info. Here you go - let me know what you think.

Hmmm, your patch is similar to mine (but goes further). First comment is display_id of null will cause an "Access Denied" error from the Views module - you should default to 'default'. Take a look at my patch, here, and see what you think: http://drupal.org/node/339754

Perhaps we can pull these two feature requests together? =)

BTW, IMHO the 6.x version of the Views Service should forget about Views 1.x - there's no need to provide a separate Views 2.x get method, because Views 1.x is not available for Drupal 6.x ... which makes things neater and easier. =)

Status:Needs review» Needs work

we likely also want to merge in http://drupal.org/node/300850 to produce a full views patch for services

I can see the reason for display_id, but I don't understand why the Services needs own plugins?

Status:Needs work» Needs review
StatusFileSize
new2.45 KB

I've rerolled the patch from #339754: Views Service views.get method can load (and handle access to) different displays in Views 2.x (by greg.harvey) with some cruft cleanup.
I'm setting this to a bug report, as access checked didn't perform properly resulting with access denied on legitimate Views.

If the services plugins are still needed this can be done in a follow up patch.

I've tried view service without or with this patch: when I test it with the Services page everything is fine, but when I use it in a python script I get the error 'Server error. Wrong number of method parameters.'.
Here you can see a screencast http://www.mediafire.com/download.php?zjjy3ezteyj of both situations.
Can someone suggest me if I missed something?

What the error message says! Look at the function in the Services module code - you need to supply the same parameters, even if you want the defaults you have to supply them for some formats. XML-RPC is one, for example. You must pass all the parameters, even if you want the defaults.

HTH =)

ok! now I got it! I thought that optional means I could not to define it!
inserting default values made the trick!
thanks for your support!

this patch would be great.

views.get doesn't currently give proper data. Formatters are not looked at so a perfect example of something that wont work, if you configure a view to display fields and 1 field is an imagefield. The view data that services will get contains only an FID value of the imagefield. If you configured the formatter for the imagefield to return a simple URL like how I have it, all that is completely ignored. You never do get anything to do with the actual image name. No image markup either. It's all the useless info :S

regarding the wrong number of params, this is a lame issue with core xmlrpc. I personally avoid using xmlrpc and switched to json_server which actually can handle the right params and avoid this bug.

so as my last point, views.get doesn't work properly.

i just rolled this patch into my install but had some fails since dev has been updated and i fixed that. i can post a new patch if wanted however i feel this views.get situation should be apart of this issue.

im trying to figure things out more but i havent done much drupal coding lately and views 2 i havent dove into the code like this before. its a beast and documentation in stuff like this does not exist.

@Steve McKenzie,
Are you refering to patch in #9?

yes. #9.

StatusFileSize
new4.03 KB

This patch is untested as I get access denied - #469748: Changes to services module - see this if you are having issues with access after installing new dev version
Anyway, this patch better uses the views API, so user can now pass another value - $format_ouput. If it is set then the result is the rendered output of the view, otherwise the result is the $view->result.

StatusFileSize
new4.08 KB

This patch is fixed, tested and ready for review.

Status:Needs review» Needs work

we still need to address a major issue.

If you do not request formatted output, the result array does not actually give you proper values. the values in the array still need to go through their field formatters.

a great example where this fails is imagefield.

[node_data_field_background_image_field_background_image_fid] => 1
[node_data_field_background_image_field_background_image_list] => 1
[node_data_field_background_image_field_background_image_data] => a:3:{s:11:"description";s:0:"";s:3:"alt";s:0:"";s:5:"title";s:0:"";}

i have my view configured to use the "URL to file" formatter for the imagefield.

@Steve McKenzie,
IMO what you ask is a feature not a bug in the proposed patch - one doesn't contradict the other. The current patch gives valid results - one is the raw results; the other the HTML (think about embedded views); your requirement should be the third way.

After 2 days' try and retry, I still cannot get the patches merged, I feel a bit hopeless. Can anybody give me a complete version of services_views package which has the patches included? Greatly appreciate any help.

Sure but getting just an fid in return is wrong in my eyes. especially the other vars existing.

Here's a snippet im currently playing with. I would have created a patch but ya..

<?php
if (!$format_ouput) {
   
$view->set_display($display_id);
   
$view->pre_execute($args);
   
$view->render($display_id);
   
$view->post_execute();
      foreach (
$view->result as $rid => $row) {
       
$node = new stdClass();
        foreach (
$view->field as $id => $field) {
         
$field_output = strip_tags($view->field[$id]->theme($row));
         
$node->$id = $field_output;
        }
       
$result[] = $node;
      }
  }
?>

this snippet also makes the field names nicer vs giving something node node_title or node_data_field_release_date_field_release_date_value

like seriously, views should return normal field names, not pseudo. its so ugly.

oh and the strip_tags was for my own use.

i'll be moving that to a cck formatter.

the main thing is the loop and clean node objects.

Status:Needs work» Needs review

The code in #22 is trying to manipulate the views output in a way that is not in views core - so maybe 'how to output it like this' - belongs in the views issue tracker.

This scope of this patch is to integrate views + services, so let's get this committed first. Setting back to needs review (patch in #18).

Really expect View2 released as a formal Module.

Status:Needs review» Needs work

@Amitaibu: will be reviewing #18, as requested, in the next few weeks. Need it for a project I'm working on. Will report back. =)

I have given this patch a quick look over and I like what I see and agree with the comment in #24. Once I get a review by the community status from either Greg, Steve or Amitaibu, i'll give patch a final review and then get it committed. Thanks for driving this issue along.

Status:Needs work» Needs review

Great, waiting for a review, and setting to the correct status.

added tag

Status:Needs review» Needs work

I could not get my formatted view back - not sure why. If I did not set my view to formatted, then I *did* get the raw view result (which I presume is expected?) but if I did set to formatted then I got a mangled version of default as a node preview or something like that. Really not sure how.

Anyway, took a look at the code and changed it slightly. What do you think of something like this?

<?php
function views_service_get($view_name, $display_id = 'default', $fields = array(), $args = array(), $offset = 0, $limit = 0, $format_ouput = FALSE) {
 
$result = array();
  if (!
$format_ouput) {
   
$view = views_get_view($view_name);
   
// Put all arguments and then execute.
   
$view->set_arguments($args, FALSE);
   
$view->set_offset($offset);
   
$view->set_items_per_page($limit);
   
$view->set_display($display_id);
   
$view->execute();
   
$result = $view->result;
  }
  else {
   
// We want to keep the result an array.
   
$result[] = views_embed_view($view_name, $display_id, implode(", ",$args));
  }
  return
$result;
}
?>

The unformatted stuff is nearly identical, but we don't bother with views_get_view() unless we need it. If we *do* want it formatted then we don't concern ourselves with messing about with the view. Just use views_embed_view() to get the rendered output automatically. Much easier and should stand changes in the view object too (should there be some in the future that might break this).

Btw, can we make $format_output *either* a boolean or an integer. It's described as an integer in the hook_services() implementation but looks like a boolean if you go to the function. IMHO it should be a boolean in both places (e.g. the callback function is correct and the hook needs to change).

All in all, the above works for me. Will await your thoughts.

AFAIK the problem with views_embed_view() is that it ignores the offset and pager, so I think $view->preview() is better.
The output you should expect when $format_output = TRUE, is the actual HTML (or other format) - what did you get when you tried it?

There is one other thing. Can anyone think of any reason why the user session might get closed after views.get method is called? I have a test file that touches system.connect to open a session, does a user.login, then a views.get and finally a user.logout. When there is no views.get then everything is fine, but after a views.get $response['sessid'] is null again.

Weird!! =(

Assigned:Steven Merrill» Unassigned

Woah, some assign weirdness there. Sorry. Must've been because our replies crossed and Drupal got confused? I've "unassigned" so you can take it back if you wish.

Anyway, I did get *some* HTML, but I should've got XML from my NITF Views module. Instead I got some weird mark-up that looked like a corrupted node teaser.

BUT I just reverted my changes and re-applied your patch, cleared caches and it worked fine! Go figure. I'm now happy your code works, but wondering how I managed to see what I saw in the first place. Probably a PEBKAC. ;-)

Are you able to comment on the session destruction, or do you think it's unrelated? Seems unrelated to me, but just in case...

Ps - looking at views_embed_view, it does what you're doing anyway:
http://drupalcontrib.org/api/function/views_embed_view/6

And looks like you're right - you can pass it arguments, but I don't think you can manipulate things like you're doing here. So yours is better. =)

But I would still make the declaring/implementation of $format_output consistent *and* correct the typo (currently called $format_ouput - missing a 't').

Assigned:Unassigned» Amitaibu
Status:Needs work» Needs review
StatusFileSize
new4.04 KB

PEBKAC is a good one ;)
Re-rolled patch to fix the boolean and $output_format name.

Title:Better Views2 SupportCouldn't do limit and offset

It simply wasn't overriding the limit and offset set in the views display when I tried to call it as a service, added the following to views2_service.inc @ line 29:

foreach ($view->display as $display) {
$display->display_options['items_per_page'] = $limit;
$display->display_options['offset'] = $offset;
}

Title:Couldn't do limit and offsetBetter Views2 Support
Status:Needs review» Needs work

resetting the title and assuming the above means code needs work?

Category:feature» bug

I THINK so? I am not familiar with how things are done in the Drupal community as I am new to posting here, but I am willing to learn. For instance, I apologize for resetting the title and status of the thread.

Its either a possible fix or I am crazy and I need to be corrected :)

Category:bug» feature

This is a patch for the views service and as such is a feature. The code will not be committed until it works correctly so basically what will happen is that the people who have been working on the patch will fix your issue and then will create a new patch for testing. That is why I changed the status back to needs work, so as some sees that their are issues with the patch. Hope that makes sense :)

Status:Needs work» Needs review

Setting back to needs review, as the code that doesn't work in #36 is simply not in this patch or in the current DEV.

@PadreHomer, please download the DEV releae of services, apply the patch - and re-test.

Status:Needs review» Needs work

@Amitaibu, I think you're misreading what PadreHomer is saying. He tested the patch and it failed to set limit and offset for his view. He's trying to provide the code in #36 as an addition to the patch so these parameters have an effect. Seems reasonable. I admit, I didn't actually test those params.

@PadreHomer please confirm this. ^^

I can still not get actual view information by calling views.get() method.

In my view, fields are defined like:

Node: Title
Content: HeadImage presenter_dead_thumb image linked to node
Node: Body
Content: HeadImage Path to file

in the services UI in drupal, after click "call method", i got following result:
-----------------------------------
Result

Array
(
[0] => stdClass Object
(
[nid] => 27
[node_title] => Bill
[node_data_field_pres_headshot_field_pres_headshot_fid] => 22
[node_data_field_pres_headshot_field_pres_headshot_list] => 1
[node_data_field_pres_headshot_field_pres_headshot_data] => a:2:{s:3:"alt";s:20:"Photo for user Admin";s:5:"title";s:0:"";}
[node_type] => presenter
[node_vid] => 27
[node_revisions_body] => blah,blah,blah,blah,blah,blah,blah,blah,blah,blah,blah,blah,blah,blah,blah,blah,blah,blah,blah,bla..
[node_revisions_format] => 1
)

[1] => stdClass Object
(
[nid] => 28
[node_title] => Bill Gates
[node_data_field_pres_headshot_field_pres_headshot_fid] => 23
[node_data_field_pres_headshot_field_pres_headshot_list] => 1
[node_data_field_pres_headshot_field_pres_headshot_data] => a:2:{s:3:"alt";s:20:"Photo for user Admin";s:5:"title";s:0:"";}
[node_type] => presenter
[node_vid] => 28
[node_revisions_body] => William Henry "Bill" Gates III (born October 28, 1955) is an American business magnate, philanthropist, author, and chairman of Microsoft, the software company he founded with Paul Allen.
[node_revisions_format] => 2
)

)
-----------------------------------

As you can see, the views.get will not return image path information etc. BUt in view, i set the "HeadImage" to Path to file, in the meanwhile, i can see the picture displayed and image path returned in drupal node page.

So there must be some not fully implemented in views_service?
How to have views.get return complete information like(the feild name is also trimed to be more clean):
[timestamp] -> 1238546233
[filemime] -> image/jpeg
[fid] -> 9
[filepath] -> sites/all/files/headshots/full.nium220.jpg

Any suggestions will be welcomed, thanks.
Andy

Finally, my issue solved, thanks gdoteof in his comments#2, in http://drupal.org/node/415314:
< this is solved in dev. make sure your views row format is 'node' and not 'fields' >

Thanks

Any tought about why I'm only getting nid and node_type when switching to "node" output instead of "fields" ?

example :

Array
(
[0] => stdClass Object
(
[nid] => 3
[node_type] => product
)

[1] => stdClass Object
(
[nid] => 2
[node_type] => product
)

....
)

Version:6.x-1.x-dev» 6.x-2.x-dev

We are having a similar issue: Our views return what we are trying to see, in our case imagecache file locations instead of the file location stored on the cck node, but when we hook up the view to a service we get what appears to be the raw output from the view if we just execute the sql, not what the view is actually giving us after the fields are processed.

NeoAndy in #44 above notes correctly that by changing the row style to node we can get the whole node, but again that is giving us the pre-processed view: none of the formatters seem to be executed (so we do not get imagecache urls).

The patch from #18 renders the entire node html, which formats individual fields correctly, but what we really want is exactly what the view is returning: just the fields selected in the view, but formatted according to how the view is configured.

Are we missing something here?

@garphy, jdblank

This is by design - if you want to get the result formatted please set $format_out to TRUE - otherwise you get the views' object unformatted result .

Has anyone else had chance to test offset and limit in the current patch, since a problem was reported? Is it a bona fide bug report, or is the patch good to go? (I haven't had chance, hence asking...)

=)

Sorry, after looking a little closer I realized that the view output is html so you're exactly right... To back up a little, what I am trying to do is use imagecache on a content type that is pulled into Flash via AMFPHP. So I am trying to get the view object, not html, but with whatever processing the view preview is doing to turn the raw values returned from the db into what the node displays.

Right now I am getting this raw object back (with format_output false on the service and my view set to return fields):
Array
(
[0] => stdClass Object
(
[nid] => 56
[node_title] => My Flash Node
[node_data_field_flash_promo_image_field_flash_promo_image_fid] => 3
[node_data_field_flash_promo_image_field_flash_promo_image_list] => 1
[node_data_field_flash_promo_image_field_flash_promo_image_data] => a:3:{s:11:"description";s:0:"";s:3:"alt";s:0:"";s:5:"title";s:0:"";}
[node_type] => flash_promo
[node_vid] => 56
)
)

If I turn on format_output, the view preview gives me this (with the image location that I am looking for) HTML:
Array
(
[0] => <div class="view view-homepage-flash-promo view-id-homepage_flash_promo view-display-id-default view-dom-id-1">
<div class="views-admin-links views-hide">
<ul class="links"><li class="0 first"><a href="/admin/build/views/edit/homepage_flash_promo?destination=admin%2Fbuild%2Fservices%2Fbrowse%2Fviews.get#views-tab-default">Edit</a></li>
<li class="1"><a href="/admin/build/views/export/homepage_flash_promo">Export</a></li>
<li class="2 last"><a href="/admin/build/views/clone/homepage_flash_promo">Clone</a></li>
</ul> </div>

<div class="view-content">
<div class="views-row views-row-1 views-row-odd views-row-first">

<span class="views-field-title">
<span class="field-content">My Flash Node</span>
</span>

<span class="views-field-field-flash-promo-image-fid">
<span class="field-content">http://mysite/sites/default/files/imagecache/flash_promo_large/image1.jp...
</span>
</div>
</div>
)

What I really want is the object but with the values from the HTML. Or alternately, if the "unformatted" option on the view really returned unformatted data instead of HTML that would be closer... Maybe I just need to write my own view formatter to put the values into a format that I can easily consume.

Update: After trying some other modules out that manipulate the views output it seems like the issue here is with the way that views (and other modules like views datasource) render output: it's either processed, marked-up html, or raw output from the sql query which is then transformed... I haven't found anything yet that will process the fields and then allow custom formatting of the output.

Update 2: Went ahead and added Steve's code from #22. That does exactly what I needed, although I agree that it seems like something that should be handles by views not services.

Thanks!

@Amitaibu (#47)
I do want raw output but I want full node data, not only the nid.

@garphy, then that's a feature request. Please see #24 and raise a separate issue if you want a feature other than the features this patch is already intending to deliver. We don't want a patch that starts a kitten massacre. =)

Forgive me, I am new to this, I was using an older version of services and the original views2 service, I see now that you have rolled better support for views 2 into the regular views service in the latest versions. My pagination update was for that old views2 service, so its way out of date.

So I have updated to the latest dev version of services, run the latest patch on the views service and I am getting now raw view results in the services. I really liked the services feed view display type that the old views2 service provided though, how do I get that back with the latest services version?

Status:Needs work» Needs review

Thanks for coming back. Setting back to "needs review". We need to test #35. Can people (myself included) please test #35 against what it is *supposed* to do, not against any additional feature requests. If we can do that without any more noise then we can mark this as fixed. =)

Status:Needs review» Needs work

I am not sure if this is what you are looking for, but $view->preview returns a string that looks like an array, not an array. So you end up with a single element array with what amounts to a "print_r" of the desired result inside of it.

Instead of $view->preview should you be using $view->render?

I can confirm that offset doesn't work - I'll re-roll. Limit does work properly.

Status:Needs work» Needs review
StatusFileSize
new4.8 KB

Attached patch disables user_pager if offset is set (otherwise offset can't be set).

Cross post to gives services views team a bit of heads up and to welcome input on this issue http://drupal.org/node/395226 (note it really is early days on this)

Title:Better Views2 Support#59

I am facing the same problem as described in many posts here :

I created a view in order to send nodes infos to flash via services and amfphp.
I need to use the raw output as fields, as I want to access the path of an image thumbnail created with imagecache.

Instead of receiving a valid file path for my image field with views.get, I have this :

[node_data_field_headline_image_field_headline_image_fid] => 94
[node_data_field_headline_image_field_headline_image_list] => 1
[node_data_field_headline_image_field_headline_image_data] => a:11:{s:11:"description";s:0:"";s:3:"alt";s:0:"";
s:5:"title";s:0:"";s:8:"duration";i:0;s:6:"height";i:400;s:5:"width";i:520;s:18:"audio_bitrate_mode";s:0:"";
s:18:"audio_channel_mode";s:0:"";s:12:"audio_format";s:0:"";s:13:"audio_bitrate";i:0;s:17:"audio_sample_rate";i:0;}

After reading the entire thread, I still cannot find how I could get what I want. Using one of these patches ? Why not, but where should I put it ? Should I replace specific functions by the ones given ?

I am quite afraid of making a mistake. I would like to be helped on that, maybe someone could write about how you add the patches to the actual code ? I would realy appreciate that.

Thank you in advance

Title:#59Better Views2 Support

@kone23, please raise an issue with the File Field module. The Services Views service just exposes the data it gets from Views. And Views gets its data from a Views plugin provided by the File Field module (see filefield_handler_field_data.inc). So there's nothing we can do here.

EVERYONE ELSE:
This issue is for testing the patch in #57 so it can be confirmed working and applied. Please don't post anything unless you have tested the patch in #57! If you have another issue, then start a new issue, don't hijack this one.

OK,

sorry about that. Thank you for the advice.

@greg.harvey,
Can you review it - so will get it in?

I'll try, but I'm really pushed for time - going on vacation at the end of the week and trying to tie up loose ends in live projects. =(

So don't hold your breath, but I'll keep it in mind and if I find half an hour I will!

Hi, I applied patch from #57 as I was making a view that displayed a list of terms by vocabulary. prior to the patch i was getting a preview in views ok, but in views.get the arrays would show nothing. I applied the patch and in views.get i am not getting all my list of terms ok.

Thanks

Hi, Has the patch from #57 been applied to the latest dev release? I upgraded my services to 6.x-2.x-dev and my views.get stopped working again for a "term view" that shows all terms. I just get empty arrays in the services preview. in views it shows the list ok.

Regards
Barry

Category:feature» bug

Hi, Has the patch from #57 been applied to the latest dev release? I upgraded my services to 6.x-2.x-dev and my views.get stopped working again for a "term view" that shows all terms. I just get empty arrays in the services preview. in views it shows the list ok.

Regards
Barry

Category:bug» feature

Not a bug this is feature, which awaiting review and until it is RBTC it won't be applied to services.

StatusFileSize
new4.21 KB

Re-rolled to remove the "fields" field - If think that services doesn't need to deal with it those fields, as one can build them in Views (also we won't control it if format_output = TRUE).

Oh, and let's get this patch in already... :)

Patch #69 working great over here. Thanks

Status:Needs review» Needs work

I gave this a runthrough today and it is solid, and while it might not meet 100% of the needs out there, it is way better than what we have now. My one big concern is that by removing the $fields argument we are breaking the old API because we have removed an argument. We also have moved things around (because display_id is the first argument now.)

I know this is a -dev, but there are 3,000+ installations out there and I'd prefer not to break them if at all necessary. Ideally the way I'd like to see this structured is with all the original fields remaining in their original order, then display_id added as the last optional parameter. This way at least the old views will continue to work. What do you think of this?

Thanks for all your patience and work on this issue everyone, it is appreciated. I am dedicated to clearing the queue and getting an RC of 2.x out within the next couple weeks and I definitely want this to be a part of it.

@heyrocker,

Thank you for the rewview. Your concerns are valid - I will change the display ID order. Regarding te fields, I'll have another look and see what can be done to save backwords compatability.

@heyrocker,
I have gone over the code again, and I think the patch from #69 should stay for the following reasons:

1) Fields are no longer used in Services - and we shouldn't maintain backward compatibility just for the sake of backward compatibility. The way one would change the view is either create a new display, or implement on for the Views hooks.
2) The implementation of $fields is node-centric (services_node_load()). Views 2 allows viewing any table, so Services shouldn't be strict about it as-well.

Maybe we can add this change in a CHANGELOG.txt to make it more visible for upgrading users.

I agree with @Amitaibu - patches need to work with -dev ... they can be back-ported/modified later, as is the way. If you need this to work with older versions of Services, it is entirely legit to start a new issue referencing this one, with the specific version of Services you need to support as version, requesting a back-port of this patch supporting fields.

Otherwise, this patch should support the latest dev snapshot only. As is the way of Drupal. Thanks be to Dries. (Oh, God, I've been doing this too long, shoot me.) =P

Status:Needs work» Reviewed & tested by the community

Given the comments #73 and #74 I happy to stick my kneck out and mark this as RTBC. Also given that views doesn't work anyway in its current version I'm sure most of the sites out there are already using a version of this patch or have rolled there own version.

OK I'm sold. This patch is committed. Thanks very much everyone.

Status:Reviewed & tested by the community» Fixed

Status:Fixed» Closed (fixed)

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

subscribe