Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

Reverse variable matching #2

Open
aslakhellesoy opened this Issue · 19 comments

8 participants

@aslakhellesoy

I couldn't find any information about this in the docs or by skimming the source code. For example - given a template /foo/{name}/bar/{id} and a URI /foo/hello/bar/world - be able to extract the name and id variables with values hello and world respectively.

Would this be within the scope of this library? The wo-furi library supports this, but since that library seems abandoned and implements an older version of the spec I'm looking for something else.

FWIW, I'd like to use this in webbit-rest

@aslakhellesoy

Follow-up - the ruby addressable project has an implementation that does this: https://github.com/sporkmonger/addressable/blob/master/lib/addressable/template.rb

It essentially turns the pattern into a regexp and then matches against the uri and then loops over the capture groups to extract variable values.

@damnhandy
Owner

If I'm understanding this correctly, you want to see if a URI matches a given expression and if it does, you want to be able extract the variable values from the URI? Obvious use case to match request URIs to patterns on the server. If that correct?

@aslakhellesoy

Yes, that's exactly it. As mentioned in section 1.4 in the spec:

Some URI Templates can be used in reverse for the purpose of variable
matching: comparing the template to a fully formed URI in order to
extract the variable parts from that URI and assign them to the named
variables.

@damnhandy
Owner

Got it. I'll target this for the 1.2 release. I have been refactoring the code a bit to separate the expression model from the template in order to make issue #1 a bit easier. This feature request fits nicely into the same refactoring. It'll take a few more days but doable.

@mwanji

+1 to this request. Would be extremely useful for a web framework I'm writing.

@damnhandy
Owner

I've been working on this here and there over the past few months and it's nearly complete. As a result of this new functionality, it will change the API considerably. For starters, the UriTemplate will now be immutable and there will be a UriTemplate.Builder class that will be used to programmatically construct a URI template. Lastly, this change will introduce a UriMatcher that will match a URI against a URI template pattern.

@plalloni

+1 to this request.

Has been any advance in this issue?

Is there any schedule for release?

We're needing this so bad that we'll roll our own if not available.

@damnhandy
Owner

Realistically, it's 2 to 3 weeks out. Juggling summer and my day job, just getting back into the swing of things

@kminder

+1. I'm in the same boat as plalloni. Will either have to deal with wo-furi or roll our own and then hopefully replace with Handy when this feature is available.

While I'm at it the other thing we will need to layer on top is to be able to pick the "best" match for a given URI from a set of candidate URITemplates

@damnhandy
Owner

On the subject of reverse mapping, this is a bit more challenging that one might think. This is especially true when you start looking at reverse mapping for level 3 and level 4 expression types. level 1 and level 2 expressions are fairly straight forward and that's close to what wo-furi supports now. I've been proceeding with the idea of trying to be bale to reverse map level 4 expressions. If folks find levels 1 and 2 acceptable for the time being, that's a tad easier.

On the topic of rolling your own implementation, let's remember that this is GitHub and this is an open source project. I'm pretty liberal on contributions. I've already taken in a few bug fixes and feature contributions are more than welcome.

@plalloni

Got back to this after some time. After all we just went with ugly hand made uri parsing & building.

@damnhandy I think level 1 & 2 would be great and enough for most cases.

@damnhandy WRT "roll our own": at that time, I was talking about rolling our own just because we target the scala language, not java, so if any effort would've been undertaken it would've been more gain for us if we offered a scala API

@damnhandy
Owner

Same here @plalloni , been a while. I've restructured the code to better support this as the initial design presented some problems. There's going to be some API changes, but this will pave the way to reverse matching as well as much better feedback on parsing errors. Version 2.0 should be available in a few days and then we'll get reverse matching in 2.1.

@damnhandy damnhandy was assigned
@damnhandy
Owner

Just a heads up, I'm planning on using Java 7 since the regex supports named groups, which in turn will make this process a lot easier. If anyone has any objections, please let me know. I'm also assuming that since Java 6 was EOL'd back in February, most folks have moved on from Java 6.

@henrib

+1 for the request; as a temporary measure, adding the URITemplateResolver and test from 2.1 branch in the 2.0 trunk using Java7 tests ok. Any status on level 3/4 resolution ?

@felipesere

What is the state on this? I could not find any Class to perform matching or variable extraction :)

@felipesere

That looks pretty interesting. I'd like to go over the code and make a pull request. Should I do it against Master or the 2.1-branch?

@faisalferoz

IMO should be against 2.1- branch. @damnhandy shud be able to tell better since he is the owner of the project.

@damnhandy
Owner

Yes @faisalferoz, use the 2.1 branch.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.