Overriding filter definition info in config file

[martindholmes]

There are a number of issues related to filter features, including #248 (allowing markup in filter labels), and #86 (allowing sorting results by filter value), and we think the way to approach this is to define a filter element in the config which allows you to override the name with a richer label, set the sortable feature, and possibly other things. This will require allowing some HTML into our config file, probably rooted on the HTML label element, so people can do styling.

The sortability feature will also require a label, so it should be a child element with a single HTML label element child.

The label element should have a language setting, presumably using @xml:lang and/or @lang. We're leaning towards @lang because it also has specialized CSS support.

The filter element needs @key which should be identical (after normalization) to the meta/@name value in the collection documents.

[martindholmes]

Plan of action:

1. Add the filter element with the label child to the config schema.
2. Add implementation and documentation for this, and close issue Allowing markup in filter labels #248.
3. Add implementation in JavaScript (see Add option for sorting results by filter values #86 for details; base implementation on URL query params).
4. Add sortability schema support.
5. Add implementation in XSLT/rendering.
6. Add documentation, and close this and issue Add option for sorting results by filter values #86.

[martindholmes]

For the sortable setting, we need:

• A generic "Sort by:" label in our captions, in the three langs we have so far.
• A default use of Unicode arrows (U+2191, U+2193) for "ascending" and descending, which we would use, unless
• The user specifies a label for ascending and/or descending in the filter config.

[martindholmes]

Some additional points:

1. Sort-by-filter settings should persist between searches, and only be cleared by the Clear button.
2. Relevance should always be the lowest-level sort filter, because you didn't ask for it.
3. docSortKey should be ignored as soon as you invoke a filter, because it's only a default.
4. We only let you use one sort filter at a time; selecting another one unsets the first one. This is best achieved by combining all sortable filters into a single drop-down so you can only select one at a time.

[joeytakeda]

Proposed idea:

<filters>
   <filter key="Document Category">
          <!--Multiple XHTML labels (for i18n) -->
          <label xmlns="http://www.w3.org/1999/xhtml" lang="en"></label>
          <label  xmlns="http://www.w3.org/1999/xhtml" lang="fr"></label>
           <!--If sortable/@value="false", 
                  then ascending and descending shouldn't exist  -->
           <!-- Content model: either empty OR ascending AND descending --> 
           <sortable value="true">
                    <!--If specified, by the --> 
                     <ascending>
                     <!--By default, the label is:
                            {$FILTER_LABEL} ({$DEFAULT_ASC}) -->
                          <label xmlns="http://www.w3.org/1999/xhtml"></label>
                      </ascending>
                     <descending>
                   <!--By default, the label is:
                            {$FILTER_LABEL} ({$DEFAULT_DESC}) -->
                           <label xmlns="http://www.w3.org/1999/xhtml"></label>
                     </descending>
           </sortable>
    </filter>
</filters>

[martindholmes]

Working on this in branch issue-268-filters.

[martindholmes]

The first phase of this is done and ready for a pull request. Note that instead of @key as planned above, I've used @filterName because we use that designation throughout the rest of our code.

[martindholmes]

The label stuff has now been merged, so the next stage is to nail down the details of the ascending/descending thing. Do we really think that each individual filter should need distinct labels for ascending and descending? I can see that there are probably different types of filter that might benefit from different labels ("earliest first", "smallest last"), but I wonder if a single global caption for "ascending" and "descending" would cover it for most cases. But if we do go for custom labels in the filter config, shouldn't we allow all the languages as well?

[martindholmes]

@joeytakeda The Jenkins build is broken for some reason. I'll try to take a look at it this weekend.

[martindholmes]

Next is the documentation of the labels. When that is done, we can close issue #248, and move on to (3) in the plan of action above.

[martindholmes]

See issue #283 before proceeding with this.