Create Views module for Services

I think that Services 2.x always will have a simple version of the views service in it - for compatibility reasons. I would suggest removing views service first in Services 3.x (which will be the first version of Services on Drupal 7).

A separated views service could support both 2.x and 3.x though. That would require it to have a different module name than the module included in core though.

I can perhaps aid as a co-maintainer - will think about it.

I will not remove views service for the 2.x branch. The support overhead of an API break was already more than I wanted, and if we remove it, the overhead will be far worse. Remember a lot of people are probably still running older dev versions, but when they see a stable release many many many more of them will upgrade. I've marked this in postponed because as of 3.x and D7, I am all for this. I just can't see leaving 4,000+ users 100% out in the cold, scrambling to grab a brand new contrib module to get their sites up again.

For 3.x, both D6 and D7, views service will not be included in the core Services package. Who wants to take it to contrib?

I can take it to contrib.

Attaching this to me for now - will hopefully get time to work on it in a few months - if anyone else want to aid then please comment here and we can collaborate.

subscribe

voxpelli, any status updates on this?

Haven't had time to start yet - have been all busy with OAuth Connector - I probably won't have time to code anything on a Views service for at least another few weeks.

I did a quick port of the views.get service from the services 2.x branch to services 3.x as a separate module (Views 2 only for now). After a little more cleanup I'm happy to post it here, but if @voxpelli or others have ideas for rewriting I'll hold off so we don't have people using dead end code.

I have always been of the opinion that Services integration with Views should be as a display plugin. It just makes the most sense and allows you to use Views as it is meant to be used. That said I haven't really talked with voxpelli much about his plans.

I agree with heyrocker that it should be a display plugin and think we should wait and see if we can have such an integration ready in time for the Services 3.x release prior to porting the existing service. If we don't have a new Views service ready when 3.x is released, then we could release a port of the old.

I was thinking that a display plugin was a likely direction for this that would offer some nice improvements. Would a services specific display plugin still be able to use the existing row plugins to output formatted html output or would it just output fields as structured data?

If it would only do structured data, maybe a completely separate "render" service could provide rendered output from views (as well as nodes or even other drupal content).

Im at a loss as to why a display plugin yields a better implementation? Whats the pros of using it this way?
As far as I can tell the "old" method of views_get_view works just fine.

Voxpelli care to explain?

There's a lot of issues reported around the shortcomings of the current extraction of data from Views. By doing a more close implementation to Views we gain more power to fix those shortcomings or to at least to avoid them from appearing in the first place.

subscribe

Subscribing

As I need this for several upcomming projects, I am working on a separate views integration module with these features. I have most of it done so should have something to show here by the end of the week depending on how much time I get to work on it. From there we can move decide what to do and move it to another project.

Ok, here an alpha level version of the module.

If no one has any objections, mainly with the module name, I can post in as its own contrib project, add co-maintainers, and we can move forward with the module in its own issue queue appropriately.

If you give me a week or two I'll take a more thorough look. At a quick glance it seems like an improvement from what we have in 2.x, but I also want to say that I myself is not yet sure what the best solution for adding Views support to Services is - so might be that we should discuss that first.

I now finally took the time to create a project for this, long overdue, sorry for that. I'm assigning this issue to that project so we can discuss it further without disturbing the Services issue queue.

I would love to hear your ideas. I have the next 4 days to work heavily on this and a good amount of time over the next couple weeks so if you post your ideas here for discussion I can hammer them out pretty quickly.

@voxpelli: It would be great to hear your ideas on moving forward with this module so that we can start work.

My approach with the code in #20 was to be as flexible as possible. Taking queues from the views menu integration. Where you can create a endpoint in views, assign the view to an existing endpoint, or non at all which would still not prevent you from using the view as resource if you wanted on any endpoint.

Also I thought of putting more control of the output into views through views theming, however much of the output is controlled in services module and the user deciding whether to output in json or xml which makes sense as it gives great flexibility.

Where I did see we could make improvement is in the option of outputting the views as it is themed instead of just the data that is returned. That is where the views theming comes to in play. So I have a basic template for the top layer of views theming, the "display" template that we can modify to our desire. I thought of putting in several other templates for "style" and "row" for things like outputting as json or any other type of output you can think of. However, there are already modules out there that provide "style" and "row" templates for most of the formats you would generally use. So I decided to leave those areas up to those modules and the user can choose what he/she needs or we could discuss the reasons and feasibility of duplicating those features.

The code in #20 is not finished. It is missing a few functions to complete the above features, namely the endpoint creation/matching part in the service display. However, I do not want to continue working on something that is going to be scrapped for some other idea. If you can put down any ideas you have we can discuss them and begin work.

I have very much to do with a few other module releases right now as well with releasing a few big projects at work. Haven't forgot about you. ANyone else who can take a look and give ideas until I get to it?

subscribe

Subscribing. Would be great to get the repo initialized for this. I might be able to contribute some commits..

subscribe +1

subscribing, willing to contribute

Committed a version 6.x-1.x - it may probably easily be ported to D7 for those who want that - open a new issue for it and I'll commit any patch.

This issue will stay open for the new improved version of Services Views.

cool, I wont have any more time this week, but I can take a look for the D7 version probably somewhere next week. will let you know if/when I start.

for an easy reference, the project is here: http://drupal.org/project/services_views

subscribing

subscribe

Won't have time for this - deassigning myself to not give a false impression.

THis ticket can be closed actually. :P