Get something working

Great!!! This is a very important initiative, and thanks for committing code. Really look forward to the maturity of this functionality.

Regarding the query type plugins, seems like a watered down version of the term and date query type plugins. I think having term_filter, range_filter, and date_filter plugins would satisfy a lot of future widget requirements.

Awesome work,
Chris

@pwolanin,

I'm getting this fatal error using the #5 patch and facet_slider from Git:
PHP Fatal error: Call to undefined method ApacheSolrFacetapiAdapter::getFilterKey() in /var/www/d7.local/sites/all/modules/contrib/facet_slider/plugins/facetapi/widget_slider.inc on line 112" while reading response header from upstream, client: 127.0.0.1, server: localhost, request: "POST /facetapi/widget/submit/facetapi_slider_widget_form_im_28_field_functiegroep/apachesolr%40ezcompany_solr_server HTTP/1.1

The slider renders as a single drag-able button and the error is displayed after clicking it...

Did I do something wrong or is the facet-slider not usable at all at this stage?

@MrHaroldA This is dependent on #1214772: Make the filter key an instance variable rather than a class const.

Sounds like a plan. I think caching the ranges is probably a good idea anyways, as they are used in other areas that would benefit from caching as well. Like anything else, optimal cache invalidation will be the trick.

@cpliakas: patching facetapi-dev (July 7th) with the patch found in #1214772: Make the filter key an instance variable rather than a class const fixed the 500 error!

Unfortunately, that didn't fix the slider which is only able to select 0 and loads the searchresults after clicking it: [0 TO 0] with a nice "Got values" notice ;)

I've started patching the code.
This are the changes made:

• Ensure that the setting for the slider is a valid number using parseFloat().
• Get the min / max slider vales in FacetapiWidgetSlider::execute().
• Make sure the form params are passed by reference to FacetapiWidgetSlider::widgetFormValidate() and FacetapiWidgetSlider::widgetFormSubmit().
  php-Background: call_user_func() doesn't support references but call_user_func_array() does.

@pwolanin
First I didn't get the intention of the construct and thus opened this, meanwhile closed, issue #1230076: Get rid of Warning: Call-time pass-by-reference has been deprecated.

Adding & to a parameter in a function call or in call_user_func() leads to a notice like this: "Warning: Call-time pass-by-reference has been deprecated".
The php documentation explicitly says "Note that the parameters for call_user_func() are not passed by reference.". Nevertheless it seems that references in call_user_func() are supported from php 5.3 upwards - there's this interesting example part in the php documentation:

call_user_func_array('increment', array(&$a)); // You can use this instead before PHP 5.3

However, since we should support php 5.2.5+ I suggest to use call_user_func_array() --> No notices, and working references.

Attached patch enhances the support for date ranges. I've only tested it with search_api_solr integration yet, thus I'm not sure if it works for other searchers too. But it definitely needs more work anyway ;)

Some clean-up to move more js-code back into php.
While doing so I remembered an extension for the jQuery UI slider which would enhance the accessibility and also solves some date related limitations of javascript.
The FilamentGroup selectToUISlider uses two select elements to create the slider - and it's released under GPL / MIT license.

But before I start do integrate this script I'd like to hear your thoughts.

@das-peter: the -15 patch doesn't apply on the latest git checkout. Which version should I use to test your patch?

@MrHaroldA: All patches base on the latest master branch of facetapi_slider. And since the last change there, was made two weeks ago I guess the problem is somewhere else.
Do you have any additional information what fails?
Did you check the git path prefix settings? I use -p1 formatted patches since the old -p0 format was phased out by May 31, 2011

I tested the Filament Group slider with JAWS 12 / FF 5. The UI pattern is a bit new for assistive technology users to get used to. But, it is well coded and does work as a slider for me as a blind screen-reader user.

@das-peter: the patch worked fine with -p1 ;)

That said, I used a taxonomy vocabulary for a list of numeric values to simplify administration of it for a client. I guess I have to convert that field to an integer-type. I got a slider with tids. Which seems to work fine though ;)

Slider works for integer fields with patch #15 and latest facetapi -dev.

I did have one small problem with the (sliderstep) and a feature proposal which I posted as seperate issues.

Update:

• Slider types split up in own classes with own js etc. Atm. the date sliders extend the normal slider widget class - but further decoupling shouldn't be a problem.
• Added Filament Group slider
• Attention: Patch depends on this patch: #1204736-2: Utilize the #tree property to determine which values should be stored as facet settings

Is there a way to provide widgets only for defined field types?

This continues on the patch of das-peter and incorporates the latest changes in facetapi so we can define what query type to use and to what query types we are restricting this widget to

Also the other widget types are working now, there was still a problem regarding the getFilterKey

Anyone would have any idea how to keep the facets on the page so people can keep redefining their slider?

Nick, gave you commit access.

~Chris

I've redone the patch with only the necessary adjustments so we can focus on getting this working first.

Committed and closing. Let's open more specific issues now

Das-peter : It would be very useful if you'd move your patch to a separate issue so we can work in parallel