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

axel.rutz created an issue. See original summary.

drunken monkey’s picture

Could 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?

geek-merlin’s picture

Issue summary: View changes

Of course! Updated summary.

geek-merlin’s picture

Hmm, even if this might be the coolest right thing to do, i don't think i can put effort into this soon.

geek-merlin’s picture

Version: 7.x-1.x-dev » 8.x-1.x-dev
Status: Active » Closed (won't fix)
Related issues: +#3191569: Add Twig plugin

Maybe this will happen some day, until then see related issue.