Problem/Motivation
There are use cases where the filter value must be processed before passing to views.
Examples
* search/replace (characters or regexp) - #2619946: Add option for token-based values to replace dashes with spaces
* provide a default value if empty - #2630914: Allow setting the default value for an exposed filter
Proposed resolution
To not clutter up the existing plugins, modifying values should be handled as a different concern from getting values, and deserves its own plugin type.
The plugin model should be the same as the well-known Feeds Tamper. Especially it must be possible that value modifiers have parameters and to apply value modifiers in any order.
Example as UI pseudocode:
Value modifiers:
* Char replace:
Field: field_foo
Search= "-",
To= "_"
* Set default:
Field: field_foo
Default: "bar*"
Count 0 as empty: Yes
* Char replace
Field: field_foo
Search= "*"
To= "%"
* Preg replace
Field: field_bar
Search="(rha[bar]?)bar"
Replace="winnie \1 wazhere"
(Note that the ordering which field is modified when is well-defined. This is different from feeds_tamper, which allows to use modified results of one field when modifying another.
Merge value and value modifiers?
While writing this i realized that value-modifiers are in fact a superset of value-providers.
Read: if we have value modifiers, we don't need value providers anymore, as anything that is done with value providers can be donde with value modifiers.
So the default value would be "value from exposed filter"; the "value from token" and "value from php" ara just value modifiers.
Remaining tasks
Decide on "Merge value and value modifiers?" above.
i (axel) tend to Yes, but existing configuration should be kept and auto-updated.
Add plugin and basic implementations like the existing ones.
User interface changes
UI for configuring and selecting plugins. See feeds_tamper.
API changes
On merge: \ViewsEviValueInterface::getValue has no access to current values. So we want e.g. \ViewsEviValueModifierInterface
As we're still in beta and there are probably not too many custom plugins if any, we can break the api.
I added a not on the project page.
Data model changes
On merge: Plugin configuration changes, simple upgrade path needed.
Comments
Comment #2
drunken monkeyCould you please elaborate a bit? How should this work in particular? It's a bit hard for me to understand how a single kind of plugin would be able to support both of these use cases?
Comment #3
geek-merlinOf course! Updated summary.
Comment #4
geek-merlinHmm, even if this might be the coolest right thing to do, i don't think i can put effort into this soon.
Comment #5
geek-merlinMaybe this will happen some day, until then see related issue.