[META] Finish incomplete match field handlers [#2704987]

Problem/Motivation

There are some match field handlers that seem to be incomplete (annotations are missing, logic is missing or using D7 apis, ...). We should fix that and re-think while doing that:

1. There are plugins that extend other ones just to support other similar field types. This seems strange. We could use plugin derivatives in this cases or add list of supported field types to the annotation (similar to formatters and widgets). Match engine currently assumes there is only one plugin per field type, which makes second solution much more tricky to implement.

2. "Unsupported" plugin is a special-case. It is only used when building the matcher configuration form. Could we drop it and re-factor matcher config form to handle this special case without relying on the plugin?

Proposed resolution

1. Port unported field matcher plugins (in per-field subtickets). Do #2705353: Implement common field matcher for simple field types first and continue with other field types once this has been committed.
2. Use plugin derivatives for different fields with the same logic.
3. Get rid of "Unsupported" plugin

Comments

Comment #1

12 April 2016 at 21:28

slashrsm created an issue. See original summary.

Comment #2

slashrsm CreditAttribution: slashrsm at MD Systems GmbH commented 13 April 2016 at 10:10

Issue summary:

View changes

Comment #3

miro_dietiker

Switzerland

CreditAttribution: miro_dietiker at MD Systems GmbH commented 16 April 2016 at 07:00

Just a note:
We sometimes provide stub plugins such as "Unsupported" to make sure when you load a record, you can rely on the API.
Method calls don't end up with fatal errors, resulting in less if / else constructs to deal with unexpected special cases when a plugin is not available.
A good example is the Past (logging) backend, where we have a Null backend implementation in case initialisation fails. Because callers should not need to deal with the special case of failed initialisation. This leads to high robustness.
Please think about this before simply removing it.

Comment #4

slashrsm CreditAttribution: slashrsm at MD Systems GmbH commented 17 April 2016 at 10:34

In this case it is a bit different. In the actual logic we have a special condition because of the stub plugin which will be gone when we remove it. It's sole purpose it so run UI, which can be efficiently done without it in my opinion.