Open crimson-knight opened 1 year ago
I'm going to expand on this a bit, when using the resources
macro, even though it accepts the block with the other request macros (get
/post
etc) it does not create the routes at all as far as I can tell. This is contrary to what the documentation says.
After doing some digging I found the namespace
macro and it does exactly what you'd expect:
routes :web, "/admin" do
namespace "/users" do
post "/login", UsersController, :login
post "/logout", UsersController, :logout
post "/sign-up", UsersController, :create
end
resources "/users", UsersController, except: [:create]
end
This produces the paths:
/admin/users/show
/admin/users/login
/admin/users/logout
/admin/users/sign-up
I found that when nesting namespaces a little deeper, the amber routes
cli tool does not show the full path. It would show the routes from the original example as if they should work, but they aren't accessible at all when passed in as a block to the resources
macro. They do work as expected when using the namespace
macro.
When I say "deeper" nested, I meant the sign-up
method url being /admin/users/sign-up
, the routes
CLI command will only show the sign-up
end-point belonging to he admin
scope and shows the URI pattern as /sign-up
. So you'd never know if it was actually /admin/sign-up
or /admin/users/sign-up
from the CLI tool.
As best I can tell, this is an issue with the resources
macro and the CLI command, not the amber router itself.
I updated my routing example after some further testing. A namespace
that shares a route base with the resource
must be defined before the resource
. Otherwise the route will match to the show
action and will cause an error because the string of the route is not a bigint
That exposes another concern: resource routes appear to be tightly coupled to integers for the actions that require an :id
in the route.
I need to explore this further, because this should be something we can change. Adding a constraints
option for the route, and/or a way to determine what the :id
of the path is should also exist. It's common to change from standard sequential ID's to slugs or UUID's and I want to ensure that Amber supports that type of routing.
If you have a route that looks like this:
I would expect the routes to be generated like this:
However, this does not happen. The routes are rendered like this:
We should fix this so that anytime you define a route within a
resources
block, it includes the named route root in the generated route