Closed kKdH closed 6 years ago
As part of rewriting the descriptor api we should keep in mind that at the moment the category flag has no display name. We are not able to translate the category as it is now. Not a big deal, just to keep in mind´
I think it would also be great to offer the possibility to group categories. I don't think that the groups would need names. Simply putting categories in one list or so to group them. This would give us the opportunity to make a simpler, cleaner and more organized UI .
Good point! With the new API it should be possible to translate categories too.
I don’t understand your suggestion about grouping categories. Can you give an example?
I'm going to close this issue for clarity of milestone progress.
In my opinion, writing descriptors for sources, filters and sinks is a pain. There are multiple reasons why we should rewrite the descriptor-api.
Problem 1: Mix of parameter definition and localization
Mixing the parameter definition an the translation of the name and description pollutes the code and make it hard to read. Additionally creating a map of descriptors (to support multiple languages) makes it even worse. In the example below taken from the
AddFieldsFilterLogic
is a lot of code related to localization and not defining parameters:Problem 2: Extraction of parameter values from a given configuration
To extract the parameter values from a given configuration i have to search through the configuration and check the parameter by its name given as string. This approach is error prone and needs a lot boiler plate code as shown in the Example below also taken from the
AddFieldsFilterLogic
:Problem 3: Automatic configuration checking
There is no automatic check whether a given configuration suits a certain logic. The developer of a filter has to write it on its own or the filter crashes at runtime due to a missing paramter.
Suggestions
ParameterDescriptors
:Proposal
Scala Example
JSON Output