You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is a little thing but it sure would add to the convenience.
If I do a match(get(myURIString)), why can't I use a URI itself, as in match(get(myURI))? In fact, it would be nice to pass parameters. That way I could do this:
URI myURI=URI.create("foo/{bar}");
match(get(myURI, "example")) ...
This implementation of get() would be something like this:
public static ConditionWithApplicables get(final URI uri, Object... values) {
return get(UriBuilder.fromUri(uri).build(values).toASCIIString());
}
The UriBuilder version might be something like this:
@garretwilson are you sure you need to have UriBuilder in the API? It also costs an extra dependency on jax-rs, which we don't use anywhere else...
I think we should absolutely support java.net.URI, but uriBuilder.clone().build(values).toASCIIString() should be happening in a helper method outside of the library, IMO.
It's been a few months since I looked at this, but I may not have realized that UriBuilder would add another dependency --- and you're right, we probably don't want to add another dependency. Although UriBuilder is part of Java EE. Maybe there could be an add-on library for UriBuilder matchers.
This is a little thing but it sure would add to the convenience.
If I do a
match(get(myURIString))
, why can't I use a URI itself, as inmatch(get(myURI))
? In fact, it would be nice to pass parameters. That way I could do this:This implementation of
get()
would be something like this:The UriBuilder version might be something like this:
Thanks for considering this.
The text was updated successfully, but these errors were encountered: