`resources` macro _should_ accept a block for nesting unRESTful routes about amber HOT 2 OPEN

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.

from amber.

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.

from amber.