Allow Override Static URLs

[da3dsoul]

I don't know what to call this.
In most languages, types are static, and you can easily say:

@route("/menu/image/<image_id>")
def get_by_id(image_id):
    pass

@route("/menu/image/unsorted")
def get_unsorted():
    pass

image_id is clearly an int or str in this context, but when we have a rule that states that get_unsorted should be called, then it should match that exact URL rather than feeding "unsorted" as a parameter to get_by_id.
Due to the fact that rules are stored as a dict, they are not predictably sorted by nature, which makes them fast, at least. When you have a situation like the above, it will randomly work or not work. If it was FIFO, then at least you could define the route that you want to be prioritized first.

The solution I propose is to get all routes that match the url, see if one matches it exactly and use that, then somehow determine which one to use instead if it doesn't match exactly and matches multiple. Ideally, it would tell the developer somehow if there are multiple matches, so developers don't need to chase a typing and regex issue like I did to find this.

[da3dsoul]

#10 fixes this

[dagwieers]

This would be wonderful. I also wondered why this was not possible as we needed this.
We actually had to refactor our interface (causing incompatibilities) because this wasn't possible.

[da3dsoul]

My fork has other things that weren't accepted. You can use it or build your own with the little change

[dagwieers]

Thanks for that, but we would prefer to use the original project with your fixes ;-)

[dagwieers]

Can we have this proposed in a separate PR?
I think this one isn't controversial.

[da3dsoul]

Oh fine I'll split them up into just bug fixes and the script stuff

[dagwieers]

Whatever makes it acceptable for merging ;-)
I hate to have to see the self-evident stuff being kept hostage over the controversial ones.
It also makes it harder to review each of the features on its own merits.

[da3dsoul]

Yeah it's totally fair. I was being lazy

…

On Sun, Aug 25, 2019, 6:51 PM Dag Wieers ***@***.***> wrote: Whatever makes it acceptable for merging ;-) I hate to have to see the self-evident stuff being kept hostage over the controversial ones. It also makes it harder to review each of the features on its own merits. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#9?email_source=notifications&email_token=ABHW6MXVJ6PCEEUDGJRCSNTQGMEHNA5CNFSM4G4AEFGKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5C5P2Q#issuecomment-524670954>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABHW6MTQCUUP6RW5OOQBAUTQGMEHNANCNFSM4G4AEFGA> .

[dagwieers]

Still waiting for that PR. ;-)

I looked in #10 and apart from #9 (#8 not so much) I see other fixes in #10 I like and would like to see those proposed in separate PRs.

[da3dsoul]

Sorry. Busy with work. I planned to do it a while ago. I'll go through each of the things I did and propose them separately. Convert Arguments as one, Script support as one, bug fixes, etc

[dagwieers]

I don't mind helping or testing. Let me know.