You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now it is not really possible to parametrize the inputs received by an Assembly component, except by implementing a separate component to manipulate the message before it is passed to the Assembly component.
One idea I've been toying with would be:
Add a control port for components that have validators
The control port would accept an object that is used together with the message when the component fires
The control object can provide static values, and also map things from the input message to the data structure expected by the component (for example using JSONPath)
This would make Assembly components quite a lot more reusable.
The text was updated successfully, but these errors were encountered:
Technically, Assembly components are just normal NoFlo components. Assembly simplifies implementation of certain patterns and component types, but doesn't enforce them. Which means that any kind of components can be used within the same graph.
Hence, I don't think that this parametrization feature should be added to every component. But rather, it can be implemented as a set of traits that one can add to certain components if needed.
Adding static values to a message object can be done by an explicit component. Similar to noflo-objects/SetProperty(Value), but supporting nesting
Changing the structure of a message object also sounds like a job for another component, which could use JSONPath to do the transformations.
But maybe i'm missing something. It would be nice to look at specific examplest to see if parametrization is more convenient than using transformer components.
Right now it is not really possible to parametrize the inputs received by an Assembly component, except by implementing a separate component to manipulate the message before it is passed to the Assembly component.
One idea I've been toying with would be:
This would make Assembly components quite a lot more reusable.
The text was updated successfully, but these errors were encountered: