Implement a matrix path variable parser #3844
Conversation
Approximates what is described at https://www.w3.org/DesignIssues/MatrixURIs.html
Empty requested keys shouldn't match if the name mismatches
| } | ||
|
|
||
| "to many axes" in { | ||
| (Path("/board/square;x=42y=0;z=39") match { |
There was a problem hiding this comment.
Is this supposed to be x=42;y=0? And why is this invalid? I might have expected extra axes to be ignored.
There was a problem hiding this comment.
The similarity to query parameters probably means that they should be. I just need to make the toAssocList stack safe since its currently capped at the number of parameters that are expected to be extracted.
| abstract class MatrixVar[F[_]: Traverse, A]( | ||
| name: String, | ||
| domain: F[String], | ||
| range: String => Option[A]) { |
There was a problem hiding this comment.
In common use, are all parameters in the matrix of the same type?
/address;city=Indianapolis;zipCode=46268
Do I have to represent zipCode as a String? If we stripped range and returned Strings, could we nest extractors?
case Root / AddressVar(city, Zip(zipCode)) =>
There was a problem hiding this comment.
I'm not really sure there is a common use. The problem I was specifically looking for was a means to solve awkward urls like /board/x/0/y/1 which implies a hierarchical structure of resources where none exists. Beyond that the goal is something that more people than just me is an ergonomic API. range is basically a mini-extractor so I will make this change.
The MatrixVar extractor is an unapplySeq for String now. MatrixVar is more permissive allowing empty kv segments and an empty name.
|
I've tried to address the comments and also make what is excepted more permissive. |
Approximates what is described at https://www.w3.org/DesignIssues/MatrixURIs.html