Fields with format "uri" and pattern specifying a schema result in type java.net.URL #918
Conversation
This is required in order to implement context-aware rules, e.g. such as joelittlejohngh-910.
jrehwaldt
force-pushed
the
derive-url-from-uri-and-pattern
branch
from
72c4944
to
6d6a376
Compare
… type java.net.URL
A field is spec'ed as follows {"type": "string", "format": "uri", "pattern": "https?://..." }
derives the type is java.net.URL.
|
I don't think I can merge this one I'm afraid, though thank you for sharing the code for others to see. You have your own definition of a URL here that is not exhaustive. URLs do not need to match You can of course solve this by using |
|
Fair enough. That's why I opened an issue about this exact situation a week ago. I understand the list is not exhaustive, but it doesn't invalidate the implementation. If at all, it makes it incomplete. Actually, I didn't expect it to be merged, but figured it would make sense to propose to change the Rule API before you release 1.0.0, because as it stands context-aware rules are not possible. Maybe I have luck with this one... |
|
What about a schema-neutral implementation checking for something like this |
The pattern is not perfect, but relatively exhaustive considering the restrictions on URL schema names. Complex nested patterns will *not* result in URL type, e.g.: * `(uri://|foo://|bar://).+` * `(uri(abc)?)://.+`
jrehwaldt
changed the title
|
I generalized it . Feel free to close if undesired nonetheless. |
|
I'm going to close this in favour of #923. |
A field spec'ed as follows
{"type": "string", "format": "uri", "pattern": "https?://..." }derives the typejava.net.URL.Fixes gh-910, depends on gh-917 and is a breaking change (API and resulting generation).