Skip to content
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

WIP: add format support to numeric types #350

Closed
wants to merge 1 commit into from

Conversation

nimerritt
Copy link
Contributor

@nimerritt nimerritt commented Nov 27, 2016

PR: for discussion
See #291 for context.

@@ -2,6 +2,7 @@
{{
var $lvl = it.level;
var $dataLvl = it.dataLevel;
var $type = it.schema.type || '';
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This could be an array according to JSON schema spec?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, can be any of basic types or integer

ajv.addFormat('identifier', /^[a-z_$][a-z0-9_$]*$/i);
testFormat();
});
describe.skip('without any type restrictions specified', function() {
Copy link
Contributor Author

@nimerritt nimerritt Nov 27, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think a reasonable approach to this is: If format is not explicitly declared in the schema then custom formatters should not be applied?

Copy link
Member

@epoberezkin epoberezkin Nov 27, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't understand. If you mean that "if type is not specified", then it is not correct. Format should be applied string and number after this change, depending on format keyword value, but even if the type is not explicitly specified. So this schema { "format": "int32" } would be valid for numbers only if they are int32 but all other types will be valid too. You need to think about keywords as about restrictions. Type keyword is also a restriction, but it does not affect format validation, data type does.

Copy link
Member

@epoberezkin epoberezkin Nov 27, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

By the way, rules are called based on the data type, not on the presence of type keyword. So the way you did it (format keyword added to two types) there can be some code added for both string and integer data type and the code in format.jst should skip adding code if type is incorrect (I think you're doing it already, and I suggested to simplify not to support arrays of types). So I don't think that type keyword should be explicitly specified for it to work.

@epoberezkin
Copy link
Member

epoberezkin commented Nov 27, 2016

@epoberezkin Perhaps it is okay to only apply the format if the type is explicitly declared in the schema?

see comment above

I think it makes sense to restrict it to just string/numeric types explicitly declared in the schema

I think there should be a way to define format for any types. Type that the format applies to should be a part of format definition with string being the default (if type is not present in the definition).

EDIT: actually it's ok, only for string and number is fine, there is no use case really to use format for arrays/objects/boolean/null, other keywords should be used for them.

@@ -81,11 +81,15 @@
var $isObject = typeof $format == 'object'
&& !($format instanceof RegExp)
&& $format.validate;
var $types = $isObject && $format.types || ['string'];
if ($isObject) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's not support formats that apply to multiple types, there is no real use case for it and it would make code simpler.

@epoberezkin
Copy link
Member

Thank you, it's getting there it seems :) Some more tests and docs and it's done. Also, I am going to merge it into 5.0.0 branch - I will release the next beta version once it's finished.

@epoberezkin
Copy link
Member

@nimerritt finished and merged in 5.0.0

@nimerritt
Copy link
Contributor Author

Thanks for finishing this up for me :) Actually needed it again today, so 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

2 participants