Closed jbfaden closed 4 years ago
I do recall that we agreed and discussed that data_$(j;pad=none).dat
is OK for formatting/generation. timeRange
sets the context.
I re-read your comment and I think that you agree that it is OK.
But I think it would be awkward to have a special case for year unless the justification was that it was generally difficult to implement versus difficult to implement in existing code.
Yes, I can put this in. It's just more code, and this is already almost 2000 lines long. This only adds about 50 more lines, because I have to keep track of the context anyway, to support $(j,Y=1999). The new code is figuring out implicitly that a context is needed, whereas before I didn't have to worry about this.
May just report "not implemented" if someone tries to use it.
I'd like to have at least one complete implementation of this, just so we have a reference implementation people can test against. (Your formatting.json is working nicely, by the way.)
This is done. The URITemplates code can have the context set so that codes like $m.dat can be parsed with a year as context.
Pro tip: You can refer to the commit that closes by copying the the commit hash into the editor, e.g., 44400f042142a0650bea137a8d29ab4b75e3c28e
Even faster, you can enter "Closes #4" in your commit message and the issue will automatically be closed and the link will be put there for you.
I will try to use your pro tip. Often there are multiple commits, though. I suppose I would just point to the last commit.
I have not tried it, but quite often I see people make a fork and then merge the fork with several commits. I think there is a way to do this with branches as well. It is somewhat difficult to motivate myself to do when I am the only person committing however.
On Wed, Aug 5, 2020 at 10:27 AM Jeremy Faden notifications@github.com wrote:
I will try to use your pro tip. Often there are multiple commits, though. I suppose I would just point to the last commit.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/hapi-server/uri-templates/issues/4#issuecomment-669225585, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAUQ57Q7IE2VEIEPU4WV35DR7FT47ANCNFSM4POXMQWA .
I don't push things that are not complete, but as I put in each change (e.g. shift modifier) I would push it. Branching is pretty easy, and I can show you how that's done if you ever need it.
Also there are things you might have a look at, for example 4626d5e3a517edb270dfb6abff478a4f68a740fe, c9f3173c9ba46463c66b2079469b4322ab054804, and b70603b559ad0c1e11b59cc34077357d92770e80
(Works, neat!)
My reading of the uri_templates spec, is that templates like
http://example.com/data_$(j;pad=none).dat
are not correct because the spec itself must contain the context. The example has 1999-01, so I think that the template should be
http://example.com/data_$(j;pad=none;Y=1999).dat
While I can see the logic that this could be formatted, ignoring the year, this causes problems for my code which assumes these are set.
See section: https://github.com/hapi-server/uri-templates/wiki/Specification#filenames-with-missing-date-information
I could probably introduce a mode into my code which would support this, but in this case I think the spec needs to be modified.