Enhance flow handling by integrating forwards dynamically#587
Enhance flow handling by integrating forwards dynamically#587stijnpotters1 wants to merge 11 commits into
Conversation
|
The border is a bit weird. Can you fix that? |
…g source handle extraction
…for improved inheritance handling
stijnpotters1
force-pushed
the
fix/dynamic-forwards
branch
from
7271630 to
db33c3a
Compare
… so tests will work
…er usage for improved JSON handling
|
I prefer if you didn't force-push when a PR is already in review, this makes it much more difficult to review |
|
| private String repairParentChains(String frankDocJson) { | ||
| try { | ||
| JsonNode root = objectMapper.readTree(frankDocJson); | ||
| JsonNode elements = root.path("elements"); | ||
|
|
||
| Map<String, List<String>> childrenByParent = groupChildrenByParent(elements); | ||
| childrenByParent.values().forEach(siblings -> | ||
| findSuccessDeclaringAbstract(elements, siblings) | ||
| .ifPresent(successBase -> repointSiblingsToBase(elements, siblings, successBase)) | ||
| ); | ||
|
|
||
| return objectMapper.writeValueAsString(root); | ||
| } catch (Exception e) { | ||
| log.warn("Failed to repair FrankDoc parent chains, returning raw JSON", e); | ||
| return frankDocJson; | ||
| } | ||
| } |
There was a problem hiding this comment.
Does this imply an issue with the frankdoc element hierarchy?
There was a problem hiding this comment.
Should be fixed in the latest @frankframework/doc-library-core version
So this hopefully isn't needed
|
|
||
| const isRouter = element.labels?.EIP === 'Router' | ||
| if (isRouter) { | ||
| const { success: _omit, ...withoutSuccess } = merged |
There was a problem hiding this comment.
What does _omit mean here?
Also I I think I commented on this before but success should be inherited from FixedForwardPipe.
Issue frankframework/frank-doc#466 of the frank-doc needs to be fixed and this code updated to accurately have the success forward on the correct elements
|
I've looked trough the code, and apart from the color generation the code seems a bit redundant. I'll close this, so all usefull parts can be implemented in a new PR. |
3 participants
Now i have made logic to make different colors for each handle type.
The thing is that we could reuse the colour logic of #536 here as well. But this needs to be merged first