For defining a custom filter, you can inherit from the class FilterPanel. This class implements the interface SearchFilter and provides the framework for implementing a custom filter easily. The state of a search filter is stored in a model bean provided by the method getStateBean() and is persisted in the preferences struct. See section Section 7.6, “Storing Preferences” for details

In your SearchFilter class, you need to override two methods. The method buildQuery() can use the current state stored in the model bean to assemble a Solr query string. Query strings from individual filters will be combined using the AND operator. By returning an empty string or null, you can indicate that the filter should not currently impose any restrictions on the search result. The following example shows how a property foo is retrieved and how a query is built from it.

public class FooFilterPanelBase extends FilterPanel {
  override public function buildQuery():String {
    var foo:Number = getStateBean().get('foo');
    if (foo === 0) {
      return null;
    } else {
      return "foo:" + foo + " OR foo:-1";
    }
  }
  ...

The method getDefaultState() returns an object mapping all properties of the state bean to their defaults. It is used for initialization, for determining whether the current state of your UI represents the filter's default state, and for manually resetting the filter. In the above example, the respective filter's default state is represented by the special value "0", and consequently, you must use "0" as the filter's default value:

  ...
  override public function getDefaultState():Object {
    return { foo:0 };
  }
}

Because the itemId of the filter component is used when identifying the filter later on, it often makes sense to specify the itemId directly in the SearchFilter subclass.

To synchronize your UI component(s) with the model state stored in the bean returned by getStateBean(), you might want to use the various existing bind plugins.