Routes `withPrefix` is not reflected in generated router

33 views
Skip to first unread message

virtualeyes

unread,
Aug 21, 2016, 8:29:57 AM8/21/16
to Play framework dev
Asked on Gitter, doubt anyone knows, so asking here as you guys likely know the answer.

In play 2.5 calling withPrefix on Routes construction appears to do nothing.

e.g. with MacWire doing something like
wire[account.Routes] withPrefix "foo"

does not prefix account routes as expected.

same deal if I construct manually a la
new account.Routes(...).withPrefix

or applying prefix in the ctor
new account.Routes(.., prefix = "foo")

Must be missing something, what's the correct way to generate prefixed routes using withPrefix?
Message has been deleted

virtualeyes

unread,
Aug 21, 2016, 9:03:10 AM8/21/16
to Play framework dev
So, one can globally prefix all routes via the main router using withPrefix, but apparently not individual sub project routers.

Is this an oversight? Otherwise, what's the point of prefix and withPrefix machinery existing in sub project routers if they can only receive main router's prefix?

James Roper

unread,
Aug 21, 2016, 9:13:10 AM8/21/16
to virtualeyes, Play framework dev
Actually what's happening is withPrefix doesn't prepend to the existing prefix in the generated router (and some other router implementations I believe), it simply replaces the existing prefix.

So, you might create a router, call withPrefix to get a prefixed router, but then when you pass that router into another router, it will call withPrefix to ensure that router is mounted at the place configured.  This will replace the prefix that you configured.

I implemented withPrefix. Before withPrefix, there was a mutable prefix property on routers, with a setPrefix method to set it. withPrefix was simply a replacement for that that returned a copy of the router. I never actually considered that the method might be understood to be used to *add* a prefix to the router, I always thought of it as a method to *set* the prefix property of the router. We could probably change it to add, and I agree that behaviour would be more intuitive, but we have to be careful in how that is propagated down to sub routers, and also how that is injected into reverse routers (which are static and hold the prefix as global state).

--
You received this message because you are subscribed to the Google Groups "Play framework dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to play-framework-dev+unsub...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.



--
James Roper
Software Engineer

Lightbend – Build reactive apps!
Twitter: @jroper

virtualeyes

unread,
Aug 21, 2016, 1:00:52 PM8/21/16
to Play framework dev, sit...@gmail.com
James, thanks.

Applying prefix in main routes file a la
-> /prefix routes.Subproject

does the same-ish thing, just trying to hack in a non-standard use case: router
accepts /prefix/path/to/foo but reverse router generates /path/to/foo

and then front end web server proxies /path/to/foo to play with /prefix/path/to/foo

Looks like not possible so will take another approach.

Side note: it would be nice if subproject routes syntax supported variable placeholder/regex. For example, this compiles but just appends regex as a String:
-> /:fooId foo.Routes

this would be useful when you have a bunch of subproject routes that all take a dynamic prefix like
/:fooId/bar/:baz controllers.foo.Foo.index(fooId: FooId, baz: String)
...
...
/:fooId controllers.foo.Foo.index(fooId: FooId)

Anyway, routing has improved tremendously -- global reverse router is awesome -- just trying to squeeze a bit more functionality out of current status quo.
Reply all
Reply to author
Forward
0 new messages