Skip to content

Conversation

@deankarn
Copy link
Contributor

No description provided.

joeybloggs and others added 25 commits July 10, 2015 11:31
investigation if goroutines in a consumer producer pattern vs passing a map
Spoiler: the map wins out big time!
whether it's a struct field or just a regular field
working on a single function to handle both to reduce
checking the same values within struct field recursion or
a regular field; this will also help reduce code complexity
and keep things DRY.
updated baked in functions:
hasLengthOf
isGt
isGte
isLt
isLte

to use utf8.RuneCountInString for string length comparisons, not counting multi-bye
characters but runes in string length comparisons.
update to use utf8.RuneCountInString for string length
update string comparisons to use utf8.RuneCountInString
initial function layouts and validation completed, still need to rework
all of the baked in functions, add map and array traversal and add back original
test cases.

NOTE: a far more pragmatic validation tests will be added, but not until it has
been proven stable with at least the old tests.
added single field validation function.
updated a few more baked in functions.
added back single field validation benchmark.
completed all validations function conversion.
updated omitempty check to continue if all ok instead of
passing tag to be validated.
updating test for the new error return formet
updated assertion functions to handle a nil Map,Slice,Ptr.....type
fixed hasValue check not comparing Interface but field Value.
Updated all tests to comply with new api.
Fix a few bugs found with validation.
Renamed for better clarity.
Added Field OrTag Benchmark.
was just keeping around for reference when converting.
when no errors occur, let's reuse the existing object.
now the benchmarks are getting back to awesome!
@deankarn deankarn self-assigned this Jul 19, 2015
deankarn pushed a commit that referenced this pull request Jul 19, 2015
@deankarn deankarn merged commit fbc15ff into go-playground:v6-development Jul 19, 2015
included within the parameter i.e. excludesall=| you will need to use the UTF-8 hex
representation 0x7C, which is replaced in the code as a pipe, so the above will
become excludesall=0x7C
Copy link

@tschaub tschaub Jan 5, 2018

Choose a reason for hiding this comment

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

Was this paragraph supposed to replace the one above ("NOTE2: comma is the default separator of validation tags")? Reading through the current docs, it is hard to understand which of , or | is the default separator.

Comma (",") is the default separator of validation tags. If you wish to
have a comma included within the parameter (i.e. excludesall=,) you will need to
use the UTF-8 hex representation 0x2C, which is replaced in the code as a comma,
so the above will become excludesall=0x2C.

type Test struct {
	Field `validate:"excludesall=,"`    // BAD! Do not include a comma.
	Field `validate:"excludesall=0x2C"` // GOOD! Use the UTF-8 hex representation.
}

Pipe ("|") is the default separator of validation tags. If you wish to
have a pipe included within the parameter i.e. excludesall=| you will need to
use the UTF-8 hex representation 0x7C, which is replaced in the code as a pipe,
so the above will become excludesall=0x7C

type Test struct {
	Field `validate:"excludesall=|"`    // BAD! Do not include a a pipe!
	Field `validate:"excludesall=0x7C"` // GOOD! Use the UTF-8 hex representation.
}

Copy link
Contributor Author

Choose a reason for hiding this comment

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

thanks @tschaub I'll correct the docs; next time if you could create a new issue that'd be great as it's confusing to have a discussion in a closed or merge issue/PR :)

fairyhunter13 added a commit to fairyhunter13/validator that referenced this pull request Jul 12, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants