[FR] more advanced router example

[ITwrx]

hi, any chance mummy could get a more advanced router example showing wildcard route segments and accessing the values of those segments to do something with them in the handler? I plan to have dynamic site sections, (preferably infinite) child sections, and pages, for instance.

An example serving a static file would be nice too. If i deploy to the web i will use nginx for serving static files, but for local dev it would be nice to just serve assets with mummy.

A route handler that matched wildcard url segments to asset dirs and files and returned the requested file is what i would be doing right now.

requested file1: "assets/js/muh.js" requested file 2: "assets/css/muh.css" route sig: "assets/*/*" route handler checks second url segment and returns requested file if it exists, and 404 otherwise.

thanks

[guzba]

any chance mummy could get a more advanced router example showing wildcard route segments and accessing the values of those segments to do something with them in the handler?

I have started to want the same thing myself after running into situations where it would be very helpful in some of my own work. This is an improvement I want to make soon.

An example serving a static file would be nice too. If i deploy to the web i will use nginx for serving static files, but for local dev it would be nice to just serve assets with mummy.

This makes sense. Serving static files in prod is great with something using sendFile syscall (like nginx will do) but locally it is really just about having something that works for dev & testing. I can make an example here.

[ITwrx]

so it seems wildcards in routes like this: router.post("/section/*/delete", deleteSectionPostHandler) work, but the handler only expects the request object, which is OK, because you can just parse the uri from the request object.

import std/uri, std/strutils

#from std/uri. 
let uri = parseUri(request.uri)

#from std/strutils
let pathSeq = uri.path.split('/')

#echo the id.
echo pathSeq[2]

This approach might be a little error prone, and may require further consideration irt security or performance or something.

@guzba did you have something more elaborate, or better, in mind?

[guzba]

The approach above should generally work out ok, and I've done something similar, but I don't love it. I want to be 100% sure that the value I use for the * in my handler matches exactly the value of * that the router matched.

Basically, I don't want a chance for two different parsing approaches to disagree and cause strange issues.

I also don't love the idea of splitting and then indexing into a pathSeq[2] blindly, since that is could be an IndexDefect which Nim has concluded cannot be caught in except (which makes no sense for HTTP servers).

I think I have no choice but to revisit the Router and support /section/{id}/delete named path parameters instead of just anonymous *. The handler proc then needs to take the map of names to values. This is what I think now before sitting down to work on this, my approach may change when working.

[guzba]

Repo working on Router improvement ideas: https://github.com/enthus1ast/matchingMummyRouter

[guzba]

A work-in-progress upgrade to mummy/routers that adds named path parameters among other things: https://github.com/guzba/mummy/pull/111

[guzba]

The improved router support for named path parameters addresses one of the major parts of this issue. This has been tagged in release https://github.com/guzba/mummy/releases/tag/0.4.0 I hope this will make working with path wildcards and accessing the values much more convenient.

As for static file improvements, I've set up a different tracking issue just for that topic over here: https://github.com/guzba/mummy/issues/113