Details
-
Work Item
-
Resolution: Duplicate
-
Minor
-
None
-
None
-
None
-
All
-
-
GreenHopper Ranking:0|i0rwjn:
-
9223372036854775807
-
Small
Description
There is some redundant pattern in the components.
For example, an input component will always have no input, at least one output and no more than 2 outputs.
We could define some archetype in order to simplify the work of a developer. These archetypes will be used as abstract classes for the runtime and the definition, and will help us to factorize a lot of code.
I currently found 13 archetypes:
Standalone component: 0 input 0 output (configuration components, connection components, tXXXRow the tjava,...) Simple input: 0 input 1 output (some of the inputs) Rejectable input: 0 input 1 or 2 outputs (most of the inputs components, the second output will be used for the reject flow) Partitionable input: 0 input 1 output (some of the inputs, may be just a specific implementation for Simple Input) Simple transformation: 1 input 1 output (ie: tFilterColumn) Rejectable transformation: 1 input 1 output (ie: tFilterRow) GroupBy transformation: 1 input 1 output (Aggregate the data, may be a specific implementation for Simple Transformation)(ie: tAggregate) Union: N input 1 output (tUnion) Replication: 1 input N output (tReplicate) Complex transformation: N input M output (tMap) Stopping output: 1 input 0 output (all the output component on Big Data, also the tassert) Simple output: 1 input 0 or 1 output (all the output component on DI, they can forward they output to the next component) Virtual Component: Need work to handle that easily