The PropertiesFilter abstract class, when extended, can describe a specific filter criteria. To implement a specific filter, one must minimally implement the getCondition() and match() methods in the PropertiesFilter abstract class.
The getCondition() method must return the condition on which the PropertiesFilter should operate.
The getValue() method must return the value that corresponds to the given condition.
The isRequired() method can be implemented to specify whether you want this to be a required filter or not. A conditional property lookup involves one or more property filters. If a filter in the filter list is required, then it must match for the overall conditional lookup to succeed. If a filter is not required, then it can fail to match without causing the overall lookup to fail.
A chain of non-required filters can be used to implement a progressively less-specific filter lookup, similar to the semantics of Java resource bundle lookup. For instance, an optional filter would be useful in a case where a locale lookup is followed by a date lookup. Given the filter {locale=en, locale=US, date=03/03/2003}, you can get it to successfully match a property with the qualifier {locale=en; date=03/03/2003} even though it does not exactly match the filter specification. This can be accomplished by setting the locale filter to be optional. The locale property type is deprecated.
The match() method returns true if this filter object agrees with or matches the condition and value that are passed in, given the information that was used to create the object.
Out of the box, the Portal Server software includes filters based on locale and client. The locale and client filter extend the PropertiesFilter abstract class and includes an implementation of the getCondition() and match() methods in the PropertiesFilter class. See the Javadoc for more details.