Support for Views Exposed Filters

Is this compatible with views 2.x?

Thanks for this patch Sepehr Lajevardi.

Although I'm having a little trouble getting it to work.
Could you explain how it works through Poster (https://addons.mozilla.org/en-US/firefox/addon/poster/).

I've tried adding a parameter of filters[0] = filterParam in poster and when I print_r($args) within services_views_access() I get the following:

(
    [view_name] => view_name
    [display_id] => default
    [args] => Array
        (
            [filters] => Array
                (
                    [0] => 2011-11-19
                )

            [q] => api/views/viewtype
        )

    [offset] => 0
    [limit] => 10
    [theme_output] => 
)

and when I print_r($filters); within services_views_retrieve() I get nothing.
I can't get this to work through the browser using this format either; http://example.com/services/views/test.json?filters[nid]=1.

I've played around with the PHP within services_views.module and services_views.resource.inc, but can't seem to get it working.
Thanks for any feedback on this. Would be cool to get this services_views fleshed out a bit more.

I managed to get this working by changing line 27 of the patch, from:

'source' => 'param',

to:

'source' => array('param' => 'filters'),

      'filters' => array(
        'name' => 'filters',
        'optional' => TRUE,
        'type' => 'array',
        'description' => 'Exposed filters array.',
        'default value' => array(),
        'source' => array('param' => 'filters'),
      ),

Thanks reevo,

But I have made this change also. Maybe it's how I'm sending the filters then...

I have a content type of say: my_content_type and it has fields like so...

my_content_type
|
|__ title (machine name: fields_title)
|
|__ date (machine name: fields_date)
|
|__ body (machine name: fields_body)

Then I have made a view that will get this content type where their is a "contextual filter" of the date field.
Meaning that I want to pass the date and if it matches this field then return that node.

If I add the date I want to check against (e.g. 2011-11-19), into the "Preview with contextual filter:", I get the correct result.
If I then add a page for that view, then go to its URL and add /2011-11-19 (e.g. http://www.mysite.com/views_page/2011-11-19), I also get the correct result.

So, if I am using a POST request, what is the query string to look like?
I have tried all these:

http://www.mysite.com/service_name/views/views_name?filters[0]=2011-11-19
http://www.mysite.com/service_name/views/views_name?filters[date]=2011-1...
http://www.mysite.com/service_name/views/views_name?filters[fields_date]...

What is the path you are successfully using reevo?

Some additional notes:
I have set "WHEN THE FILTER VALUE IS NOT IN THE URL" on the "contextual filter" to "Display all results for the specified field" and when I drop the query string it correctly returns all results, so, I know that the view is working through services.

Also, when I print_r($args) in services_views.module in function services_views_access I get:

(
    [view_name] => dailydilemma_results
    [display_id] => default
    [args] => Array
        (
            [filters] => Array
                (
                    [0] => 2011-11-19
                )

            [q] => service_name/views/views_name
        )

    [offset] => 0
    [limit] => 10
    [theme_output] => 
)

Why is the filters array within the args array and not on the same level as args, is this to do with the way the query string is written?

One more thing; If I got to......

Thanks

FOUND SOMETHING: I uninsulated services_views and reinstalled and bam! filters is now apart of the top level objects. UNISTALL & REINSTALL services_veiws after making structural changes!

I'll get back to ya'll when I have the full solution.

Ahhh, yes - resource definitions get cached. I did clear Drupal's cache after making the change, don't think a complete uninstall & reinstall is necessary.

My path was pretty much the same as yours, except using different filters:

http://example.com/service_name/views/view_name?filters[group_audience_g...

Well, I can get all the filter passing sorted, except that it doesn't return filter results.

Any chance someone can export a test view that works with services_views and filters, and the services_views module source code you have implemented, so I can run it on my Drupal install?

I've been bashing at this for ages now and need to find an answer. Thanks.

This patch works great on 6.x as well.

I just installed D7 services and services_views, created a view called "events" added a date filter, exposed it, exposed the operator and I can use my filter this way:

/rest/views/events?start_op=>%3D&start[value]=1325147817&items_per_page=5

Where start is my exposed date field, items per page is my exposed pager etc. I did this WITHOUT any patches. What is missing?

So, I should have searched first, but I just did this exact thing. My patch is pretty much the same but with more description. They both work fine; I am just including it because I spent the time to make it. Either one should be fine.

Question, though. Is the descriptions for resources not meant to be put through t()?

zzolo's patch works for me

This would be a great addition. What's the status on this issue? When would a patch for this be incorporated so that remote clients can use this feature?

Which patch should i use?

The solution by zzolo works...both the patches do the same thing.. But they won't work by applying the patch directly cause the latest version of Services Views has some other differences/conflicts in the callback function which I believe was done after their patch was released. It's a very tiny implementation so I think it makes more sense to just copy paste and edit the code manually than to rework the above patches. I've done that and it works perfectly. I suggest that to you too.

Let me know if I can help in anyway to get this feature released. Lot of people wanting it and before they branch out and apply their own edits locally, it's best to release this main stream.

Committed. THanks guys!

Good job guys! This was very much needed.

I think the next step would be to implement support for exposed sort criterias? Should we create a separate patch/issue for this?

Yeah new separate patch and issue please.

I am also able to access and use exposed filters without using the filter keyword.. My example below works for the GeoLocation (exposed) filter..

http://www.mysite.com/rest/views/test?field_location_distance[latitude]=44.261857&field_location_distance[longitude]=-88.397844&field_location_distance[search_distance]=1000

This returns all nodes located within 1000km of the Lat and Long provided.

I am uncertain why a patch was needed and why to use the "filter" keyword. In fact, I had no luck making it work with the above filters..