-
Notifications
You must be signed in to change notification settings - Fork 2
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
Can anyone explain the regexps in #match and #consume #7
Comments
Ok got it. When we define a route with the dsl such as on "posts/:post_id/comment/:id" do |post_id, id|
... Cuba needs a way to compare that with every request that comes in to see if the actual path matches our route. The most obvious way would be to use regexps such as in this psedo code
But as our DSL definition stands it wont work as a regexp. So Cuba needs to interpret our rule and convert it into a regex. This happens in #match
where segment is a parameter with a default value of "([^\/]+)" and matcher is our dsl rule "posts/:post_id/comment/:id" the result of the gsub is and that is the regexp that Cuba will use to check against the response path. The ([^\/]+) regex simply means match any non / or \ characters once or more times i.e. the 56 in posts/56 would match this. |
ConsumeNow in #consume Cuba uses the previously constructed regex to check if it matches the given path.
Now whilst I can understand what the above is doing I dont know how it is doing it. Can any @codereading/readers help with this regex? I understand
is difficult to understand. Why is it in double brackets? And why what is this checking for
|
Useful. But I'm not sure the advantage here since the double-parens mean that it does capture the closing forward-slash or end-of-line. So I don't see any difference between this and |
I don't think /\A/(#{pattern})((?:/|\z))/ is better performing than /\A/(#{pattern})(/|\z)/, and I could not find any other evidence while running a simple benchmark (see https://gist.github.com/3223768):
You may note that I tried a third regexp as well, because I guess the expression should not only match / but also \ at the end. By the way, you may find the regexp idiom ((?:x|y)+) when a repeated group should be captured. For example ((?:ab|cd)+) matches abcd and captures abcd, while (ab|cd)+ also matches abcd, but captures only cd. |
Very nice catch guys! I think @soveran has already pushed the revision (07d77d4). @codereading == win! :-) |
@ericgj and @theldoria sorry for the late reply. thanks very much for explaining that and great that it contributed to a revision. |
The issue was this covered in this thread: codereading#7 (comment) Turns out it was something we overlooked, based on a previous implementation.
@codereading/readers
consume(matcher.gsub(/:\w+/, segment))
and
match = env["PATH_INFO"].match(/\A\/(#{pattern})((?:\/|\z))/)
just what exactly are these two regexps doing?
The text was updated successfully, but these errors were encountered: