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
More constraints #72
More constraints #72
Conversation
and for "required" include all which have issues recorded against them
also keep constraints as a list, not a map (eg if multiple forbiddenIfs), and update checks to expect json
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.
Looks good @ahgittin except few comments on how the constraints are enforced
.forEach(config => { | ||
for (let [key, constraint] of Object.entries(config.constraints) ) { | ||
for (let constraintO of config.constraints) { |
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.
s/contraint0/constraint
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.
deliberately constraintO
to indicate constraint-object
. don't mind if someone wants to use different var names but don't think it's necessary.
@@ -287,8 +297,28 @@ function BlueprintService($log, $q, $sce, paletteApi, iconGenerator, dslService) | |||
} | |||
break; | |||
case 'regex': | |||
if (!entity.config.has(config.name) || !angular.isDefined(entity.config.get(config.name)) || !(new RegExp(constraint).test(entity.config.get(config.name)))) { | |||
message = `<samp>${config.name}</samp> does not match the required format: <samp>${config.constraints.regex}</samp>`; | |||
if (entity.config.has(config.name) && angular.isDefined(entity.config.get(config.name)) && !(new RegExp(args).test(entity.config.get(config.name)))) { |
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.
This is missing the condition where the configuration is not set. In this case, it obviously doesn't match the regex therefore is invalid
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.
i think the meaning of regex
should be "if a value is set it must match the regex". that is strictly more usablel (else we cannot express that). can always combine with required
if you want to make it required and having to match the regex.
} | ||
break; | ||
case 'requiredIf': | ||
if (!entity.config.get(config.name) && entity.config.get(args)) { |
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.
Should you check for empty string here?
} | ||
break; | ||
case 'forbiddenUnless': | ||
if (entity.config.get(config.name) && !entity.config.get(args)) { |
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.
Should you check for empty string here?
} | ||
break; | ||
case 'forbiddenIf': | ||
if (entity.config.get(config.name) && entity.config.get(args)) { |
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.
Should you check for empty string here?
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.
yes, these probably should be isSet(key)
where we introduce isSet
to mean config.has(key) && isDefined(config.get(key))
(as used in regex)
make tighter around things like `false` values and empty string
@tbouron i think the logic now (after last push) does the best thing for corner cases such as blank string (counts are being set but not acceptable when "required") and false (also counts as being set). also it's a bit simpler. can you eyeball and merge? i've tested it with the blueprint at apache/brooklyn-server#999 (comment) and it seems to work as expected. |
NP, will review tomorrow morning @ahgittin |
message = `<samp>${config.name}</samp> is required`; | ||
} | ||
break; | ||
case 'regex': | ||
if (!entity.config.has(config.name) || !angular.isDefined(entity.config.get(config.name)) || !(new RegExp(constraint).test(entity.config.get(config.name)))) { | ||
message = `<samp>${config.name}</samp> does not match the required format: <samp>${config.constraints.regex}</samp>`; | ||
if (isSet() && !(new RegExp(args).test(val))) { |
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.
Should the regex constraint respect default values? e.g. if a username
config key has a default of brooklyn
and a constraint of regex: [a-z]+
, then I think we should not force the user to override the default. I can imagine other defaults, like a default cidr with a regex enforcing that a user-supplied cidr is in the right format.
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.
@aledsage you're asking what if the default value is invalid? i think it would be weird to give a user error in that case. it probably is an error, but on the upstream blueprint author's part, not the consumer's part. so i think we shouldn't -- and we don't currently -- test the default value.
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.
confirmed verbally w aled -- good to merge
Adds UI support for constraints introduced in apache/brooklyn-server#999