right now, we have

Pretty paths will be generated as "search/url/segment1/segment2/".
- By default, a segment will look like: "<alias>/<value>".
- For taxonomy terms it outputs the id as well: "<alias>/<term-name>-<term-id>".

there are some @todo notes in the code where i believe we could make this pluggable.

use cases might be
- allow other facet types to be processed differently
- allow other modules to implement differnent url-encoding methods (right now we use pathauto to make pretty paths from term-names for example).

Files: 

Comments

Version:» 7.x-1.0-alpha2
Category:task» feature

Yes, it would be great to have full control over the paths generated.

Version:7.x-1.0-alpha2» 7.x-1.x-dev

would love to see proposals as a text or even better by submitting patches :)

attached a patch as an idea.

another possibility, as discussed with mh86:
define mappers in info hook as callbacks that other modules can alter
- 1st level: per field-type (taxonomy, entity reference, ...)
- 2nd level: per facet / realm?

Title:Plan pluggabilityPlan & implement pluggability
Status:Active» Fixed

committed pluggability.

This introduces a new ctools plugin type "coders" which allows for having different implementations for the helper functions:
- encodePathSegment
- decodePathSegmentAlias
- decodePathSegmentValue
- prettyPath

two coder implementation plugins are provided by default
- FacetApiPrettyPathsCoderDefault
- FacetApiPrettyPathsCoderTaxonomy

coder plugins are registered using hook_facetapi_pretty_paths_coders and may be altered as well: hook_facetapi_pretty_paths_coders_alter

facetapi_pretty_paths_coder_callback handles selecting the right coder implementation for a given task. you can define different coders on a per-facet basis, see facetapi_pretty_paths_facetapi_facet_info_alter

Status:Fixed» Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

Issue summary:View changes

Updated issue summary.