Closed prepor closed 7 years ago
Hmm. Now I see from tests that you have different thoughts about keywords with namespaces...
But my approach looks like more flexible :)
What's the use-case here? The current Ataraxy module assumes that by default you want to start a handler with <project-name>.handler
, which fits in with Duct's file structure.
Use-case is trivial and I think is pretty common. You have a lot of middlewares defined in libraries, like duct.middleware.web/webjars. And I want to use them, but only for a part of my routes.
Currently, this is not "by default", but the only way, so you can't reference middlewares/handlers from foreign namespaces.
Use-case is trivial and I think is pretty common. You have a lot of middlewares defined in libraries, like duct.middleware.web/webjars.
Ah, so it's the middleware you want. That makes sense.
Currently, this is not "by default", but the only way
No, it's just the default. You can always assign your own keywords to middleware by overriding the values in :duct.router/ataraxy
:
{:duct.core/project-ns foo
:duct.module/ataraxy
{"/" ^:auth [:index]}
:duct.router/ataraxy
{:middleware {:auth #ig/ref :buddy.middleware/basic-auth}}
:foo.handler/index {}}
Given that fully namespaced keywords are rather verbose, I don't think we should necessarily encourage that style over just setting up a shorter alias.
It might be reasonable to do a search of the configuration file for relevant keys, however. For example, the default for :foo
could be to search for :*.middleware/foo
, where the first part is a wildcard.
Cool, thank you for the help!
to refer third-party middlewares for example