-
Notifications
You must be signed in to change notification settings - Fork 26
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fragment processing faliure handling - fallback strategies #466
Comments
@scypio thanks for the ticket. Looks great. I'd add following statements/design decisions regarding implementation: Each Knot that processes Fragments:
|
@scypio Additionally:
|
@scypio, @marcinczeczko few thoughts/designs from me: I like very much the idea of having a place in markup to define the fallback. I agree that this should be later consumed as a separate
class Fragment {
String content;
String type;
JsonObject attributes;
...
} Example:
type = "snippet";
attributes.put("knots", new JsonArray(knots));
type = "fallback";
attributes.put("fallbackId", fallbackId)
|
fallback strategies looks nice but still extending snippets based on markup syntax is not a way to go in my opinion / not enough universal, see #462 (comment) how about
based on
|
Fallback is totally re-worked in Knot.x 2. |
Problem statement
Pages may contain multiple knotx snippets. Failure in processing a single snippet may result in the whole page returning 500 Error respononse.
Let's assume that a page contains two snippets:
When databridge / unstable-service fails the whole rendering process is terminated with a 500 Error.
Proposed solution
I would like to:
Blank fallback strategy
would just skip rendering of the failed snippet altogether.Static fallback strategy
would render a static markup defined as a snippet attribute.For example, should following fragment fail:
the text
No data available
would be rendered as a fallback.Alternatives
I wondered if fallback could be defined as an embedded node,
I decided I would rather not process the internals of the snippet thou.
Additional context
Once the fallback feature is implemented in the knotx core we would like to take advantage of it in the data-bridge module.
e: edited to rename the fallback attribute to just "data-knotx-fallback"
The text was updated successfully, but these errors were encountered: