-
Notifications
You must be signed in to change notification settings - Fork 92
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
POC: MINIFICPP-985 - Implement listvalidators #618
base: master
Are you sure you want to change the base?
Conversation
class ListValidator : public PropertyValidator{ | ||
public: | ||
explicit ListValidator(T val) | ||
: PropertyValidator("LIST_VALIDATOR"), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The name should somehow contain the underlying validator's name to work properly with C2.
This should be adjusted to the way Java MiNiFi or NiFi works.
That's why I made getName() virtual.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The name pattern of non-list validators in nifi seem to be _VALIDATOR, and the pattern of list validators seem to be _LIST_VALIDATOR. [1]
I suggest cutting the _VALIDATOR suffix from the inner validator, replace it with _LIST_VALIDATOR suffix and pass that to the base class ctor. I'd also avoid making getName()
virtual, since all the derived classes can already specify their desired names through the base class ctor parameter, so making it virtual would be a second customization point for the very same thing.
std::string replace_last(std::string str, const std::string& search, const std::string& replacement) {
str.replace(str.find_last_of(search), search.size(), replacement);
return str;
}
template<typename T>
ListValidator<T>::ListValidator(T inner_validator)
:PropertyValidator{ replace_last(inner_validator.getName(), "_VALIDATOR", "_LIST_VALIDATOR") },
[...]
class ListValidator : public PropertyValidator{ | ||
public: | ||
explicit ListValidator(T val) | ||
: PropertyValidator("LIST_VALIDATOR"), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The name pattern of non-list validators in nifi seem to be _VALIDATOR, and the pattern of list validators seem to be _LIST_VALIDATOR. [1]
I suggest cutting the _VALIDATOR suffix from the inner validator, replace it with _LIST_VALIDATOR suffix and pass that to the base class ctor. I'd also avoid making getName()
virtual, since all the derived classes can already specify their desired names through the base class ctor parameter, so making it virtual would be a second customization point for the very same thing.
std::string replace_last(std::string str, const std::string& search, const std::string& replacement) {
str.replace(str.find_last_of(search), search.size(), replacement);
return str;
}
template<typename T>
ListValidator<T>::ListValidator(T inner_validator)
:PropertyValidator{ replace_last(inner_validator.getName(), "_VALIDATOR", "_LIST_VALIDATOR") },
[...]
class MultiChoiceValidator : PropertyValidator { | ||
public: | ||
explicit MultiChoiceValidator (const std::set<std::string>& choices) | ||
: PropertyValidator("LIST_VALIDATOR"), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it OK for MultiChoiceValidator
to have the same name as ListValidator<T>
? I couldn't find validator names referenced in minifi-c2, so I don't know whether this causes problems with C2.
Closing this because of inactivity. |
Reopening to bring back the topic - seems we will need this more and more |
Thank you for submitting a contribution to Apache NiFi - MiNiFi C++.
In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:
For all changes:
Is there a JIRA ticket associated with this PR? Is it referenced
in the commit message?
Does your PR title start with MINIFICPP-XXXX where XXXX is the JIRA number you are trying to resolve? Pay particular attention to the hyphen "-" character.
Has your PR been rebased against the latest commit within the target branch (typically master)?
Is your initial contribution a single, squashed commit?
For code changes:
For documentation related changes:
Note:
Please ensure that once the PR is submitted, you check travis-ci for build issues and submit an update to your PR as soon as possible.