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

JsonType: Allow to use : in regex filter #5273

Merged
merged 16 commits into from Dec 22, 2018
Merged

JsonType: Allow to use : in regex filter #5273

merged 16 commits into from Dec 22, 2018

Conversation

ellisgl
Copy link
Contributor

@ellisgl ellisgl commented Nov 20, 2018

Fixes #2501
Fixes regex filter handling in Util\JsonType

@DavertMik
Copy link
Member

Looks good to me but I don't understand what's happening there 😛
Could you add some inline comments to your code?
I know regex is complicated by itself but some minor comments would help

@ellisgl
Copy link
Contributor Author

ellisgl commented Dec 4, 2018

Looks good to me but I don't understand what's happening there 😛
Could you add some inline comments to your code?
I know regex is complicated by itself but some minor comments would help

I'll get comments in tonight.

@ellisgl
Copy link
Contributor Author

ellisgl commented Dec 5, 2018

Looks like wercker/build stuff needs to fixed.

@Naktibalda Naktibalda changed the title Issue 2501 JsonType: Allow to use : in regex filter Dec 14, 2018
@Naktibalda
Copy link
Member

I tried to match time with 'time' => 'string:regex(~\d\d:\d\d:\d\d~)', in my project,
so I copy-pasted your patch to see if it works.
Matching works correctly, but one thing it messes up is error message.

Here is the output I got:

 Fail  `time: '2018-12-21'` is of type `string:regex($$0)`

I would like to see the actual pattern instead of $$0.

This issue was visible in my failed attempt to create failing test: https://travis-ci.org/Codeception/Codeception/jobs/467890679

Failed asserting that '`text: '21@:00'` is of type `string:regex($$0):\dd$~)`' is true.

@ellisgl
Copy link
Contributor Author

ellisgl commented Dec 21, 2018

Doesn't everyone know what $$0 is? 😂

I'll look when I get home. It'll probably be a case of just having to create a second array of the original, before the replacements.

Other than that, another way to kill off these issues would invlove rewriting the "API" to look like 'Array Key' => ['type' => string, 'filter' => ['regex'=> '/.*/']]

@Naktibalda
Copy link
Member

It should be enough to use a different variable instead of $type to store result of preg_replace_callback to avoid overriding original value of $type.

@ellisgl
Copy link
Contributor Author

ellisgl commented Dec 22, 2018

OK - so there actually was an issue with the regex I was using which prematurely stopped on that example you gave (Which I had a pattern I wrote during the last commit that I thought was overkill, but I guess it wasn't). I also had to just replace the $$\d+ in the type. Reason for this was because of the split on | and the split on : would have still caused some issues if I had just used a second variable for the regexes. I also did some fixes around PHP Inspections (EA Extended) suggestions.

Copy link
Member

@Naktibalda Naktibalda left a comment

Choose a reason for hiding this comment

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

It looks good to me now.

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.

None yet

4 participants