Configuration that maps snippets to flows

[dkornas]

I will try to refer to terms and concepts introduced by Knot.x 2.0. Apologies if I use incorrect terminology.

Currently a snippet processed by Knot.x is recognized by a specific tag present in the HTML markup of a template pulled from repository (e.g. a CMS). That snippet bears the information about the flow a snippet will be processed through, including handlers, transitions etc.

A proposed change to that approach is to move flow reference from the snippet to Knot.x configuration and maintain the connection between the snippet and the flow on the Knot.x side. That is, to let the snippet identify itself by name provided in the value of a data attribute of a top-most, wrapping tag. For example if a snippet represents a news list HTML component, there will be a data attribute like data-snippet-name="news-list" provided in the wrapping tag. Notes:

• the attribute name can be a configuration setting, so Knot.x may be configured which data attribute holds the name of the snippet.
• the snippet name does not have to by a unique identifier. It can represent a class of snippets news-list or a single unique snippet news-list:main.

Then, on the Knot.x side, a configuration would have to be written in a way that it holds flows (like it's planned for knot.x 2.0) and a list of name-to-flow mappings. For example, for flows:

{
    "flow-1": {
    //configuration
    }
}

{
    "flow-2": {
    //configuration
    }
}

and snippets news-list, cart there will be a mapping entry like:

news-list: flow-1,
cart: flow-2

Benefits:

1. Simplified change management and deployments. By rearranging configuration like it has been described above, changes to the flow or even which flow given snippet will go through, do not require a deployment on the repository (CMS) side. Any cross-cutting changes, which affect all snippets, will be easier to introduce, because they will require config changes and not snippet markup changes.

2. Responsibilities sorted Repository does not have to know about details of how Knot.x is going to process the snippet. Considering classic MVC (model-view-controller) pattern, repository that is the view should not have the responsibilities of a controller - which decides how to use the view and the data (the model). In the proposed approach, this decisions is moved to Knot.x which plays the role of a controller.

3. Data as the contract The only contract between the snippet provided by the repository and Knot.x, is the format of data a snippet expects to be filled in. This is expressed by the data placeholders in it. For example: Placeholders like {{obj.prop1}} or {{obj.prop2}} define a contract of data to be provided to be an object with two properties: prop1 and prop2. This makes the snippet reusable across other solutions and tools that are capable of evaluating templates.

[tomaszmichalak]

Hi @dkornas, I really like this idea. All benefits are clear and looks like a good solution. Let me explain what we have now:

The current approach assumes that all snippets:

<knotx:SOME_ALIAS>
</knotx:SOME_ALIAS>

are processed by Knot.x. Here is the resource we use in the unit test.

You can see that all tag attributes, such as <knotx:SOME_ALIAS myAttribut=1>, go to Fragment as a configuration.

It has not yet been documented, but all fragments containing flow or flowName attributes are processed by Knots.

When we compare the current approach and your idea, we have:

expected solution

<div data-snippet-name="news-list"></div>

current approach

<knotx:news-list flowName="flow-1"></kntox:news-list>

Additionally, the Splitter logic can be exchange to your custom / project implementation very easily. Fragment API fits both cases.

Let me know what do you think. Once again, thank you for your time.

References

• https://github.com/Knotx/knotx-knot-engine/issues/3

[tomaszmichalak]

Still open topics:

• the custom Knot.x tag <knotx:SOME_ALIAS> that forces CMS to have dedicated components
• the flow configuration is in the tag attribute (in your example we have only the alias)

The discussion is still opened. The outputs will be implemented in Splitter logic.

[dkornas]

It must be possible to map multiple fragments to a single flow. It would be great not to repeat entire flow configuration for each fragment that actually needs the same flow.

Also please remember about the div instead of knotx:snippet tag as the overall idea is to make the CMS agnostic of Knot.x

[tomaszmichalak]

It must be possible to map multiple fragments to a single flow. It would be great not to repeat entire flow configuration for each fragment that actually needs the same flow.

Sure, this is very important. In the configuration we can define some aliases and then they are used in markup (one to many relation). The module configuration uses HOCON syntax so you would be able also to extract some "common" parts with HOCON substitutions.

Also please remember about the div instead of knotx:snippet tag as the overall idea is to make the CMS agnostic of Knot.x.

It looks that we can implement two Splitters:

• one that works with the div tag - but it will be not as efficient as the current one, we have to analyze HTML markup
• current, which defines its own knotx:FRAGNENT_TYPE tag - works on regular expressions, so we expect more performance