Feature/fragment processing failure handling

[scypio]

IMPLEMENTATION IN PROGRESS

Description

Implementation of #466

Motivation and Context

Screenshots (if appropriate)

Upgrade notes (if appropriate)

Types of changes

• [ ] Bug fix (non-breaking change which fixes an issue)
• [x] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist:

• [x] My code follows the code style of this project.
• [x] My change requires a change to the documentation.
• [ ] I have updated the documentation accordingly.

---

I hereby agree to the terms of the Knot.x Contributor License Agreement.

[scypio]

Features implemented so far:

1. Simple blank fallback

just add knotx-data-fallback="BLANK" to your snippet:

<knotx-snippet data-knotx-knots="databridge,handlebars" 
  data-knotx-databridge-name="unstable-service"
  data-knotx-fallback="BLANK">
      {{#if _result}}<h2>{{_result.count}}</h2>{{/if}}
</knotx-snippet>

2. Static markup fallback

create a fallback snippet with data-knotx-fallback-id attribute and point to it in your snippet:

<knotx-snippet data-knotx-knots="databridge,handlebars" 
  data-knotx-databridge-name="unstable-service"
  data-knotx-fallback="CUSTOM">
      {{#if _result}}<h2>{{_result.count}}</h2>{{/if}}
</knotx-snippet>
<knotx:fallback data-knotx-fallback-id="CUSTOM">
  <p class="error">error</p>
</knotx:fallback>

3. Global blank fallback

to apply BLANK fallback to all snippets by default configure defaultFallback attribute within snippetOptions - apply these to both Splitter and FragmentAssembler.

  snippetOptions {
    tagName = knotx-snippet
    paramsPrefix = data-knotx-
    defaultFallback = BLANK
  }

4. Global fallback with custom markup

to apply custom markup fallback to all snippets by default:

• configure defaultFallback attribute within snippetOptions
• define your own fallbacks property within snippetOptions
• apply these to both Splitter and FragmentAssembler.

  snippetOptions {
  tagName = knotx-snippet
  paramsPrefix = data-knotx-
  defaultFallback = CUSTOM_GLOBAL
  fallbacks = [
    {
      id = CUSTOM_GLOBAL
      markup = "<knotx:fallback data-knotx-fallback-id='CUSTOM_GLOBAL'><p class="error">error</p></knotx:fallback>"
    }
  ]
  }

  5. fallback with custom FallbackStrategy

  you can deliver your own class that will be fired by the assembler if given fragment fails

• implement FallbackStrategy interface

  
  import io.knotx.dataobjects.Fragment;
  import io.knotx.dataobjects.KnotContext;
  import io.knotx.fallback.FallbackStrategy;

public class MyFallbackStrategy implements FallbackStrategy {

@Override public String getId() { return "CUSTOM_STRATEGY"; }

@Override public String applyFallback(Fragment failed, Fragment fallback, KnotContext knotContext) { return "

markup

"; } }

- make sure that `ServiceLoader` can discover this class - add its fully qualified name to `/META-INF/services/io.knotx.fallback.FallbackStrategy` file. 
- create a custom fallback snippet with linked strategy Id

<knotx-snippet data-knotx-knots="databridge,handlebars" data-knotx-databridge-name="unstable-service" data-knotx-fallback="CUSTOM"> {{#if _result}}

{{_result.count}}

{{/if}}

error

```

[tomaszmichalak]

I am wondering if this tag data-knotx-fallback="BLANK" is really required. We can assume that if there is no data-knotx-fallback-id tag defined, then the default fallback mechanism should handle the snippet.

[tomaszmichalak]

According to 5: We agreed that a fallback strategy should be configured as a chain, something like:

"fallbackStrategies": [
   { "name": "CUSTOM", conf":"{next:"DEFAULT"" }},
   { "name": "DEFAULT", "conf":"EMPTY" }
]

In that way our fallback strategy implementation should pass the flow to the next fallback. I thought about something similar to io.knotx.server.handler.knot.KnotEngineRoutingHandlerFactory.KnotxEngineHandler#handleRoute.

[tomaszmichalak]

Can we move this comment to the SnippetFallback.md file - we could work on documentation in the same PR. We plan to move documentation from wiki to *.md files so it can be good option.

[malaskowski]

Please see my https://github.com/Cognifide/knotx/issues/466#issuecomment-435311790. I described there few implementation details that will make this solution easier to extend in the future.