[2.0] [Scala] routes for controller sub-packages

[Toby M]

I'm unable to get a reverse route to a controller that is in a
subpackage of controllers.

I have a controller like this:


package controllers.foo

import play.api
import play.api.mvc._

object Home extends Controller {

def index = Action { implicit req =>
Ok(views.html.foo.index())
}

}

The template file is in /app/views/foo/index.scala.html.

The matching route is: GET /
foo controllers.foo.Home.index()


This renders fine, but if I try to include the reverse route like
this:

<a href="@controllers.routes.foo.Home.index()">Home</a>

This will fail with an error in the template file: value foo is not a
member of object controllers.routes

Am I doing it wrong? Thanks

[Julien Richard-Foy]

You’ll be able to find the right path to your action in the generated
code (in src_managed).

I keep thinking that Play should generate all routes in a “routes”
root package (and then it should follow the path given in the
conf/routes file).
Guillaume, do you see any jeopardy in this approach?

[Guillaume Bort]

There is a routes subpackage for each controller package. So the right
fully qualified name of your route is:

@controllers.foo.routes.Home.index()

It's done this way to "see" the routes subpackage relatively from any
controllet package as "routes"

> --
> You received this message because you are subscribed to the Google Groups "play-framework" group.
> To post to this group, send email to play-fr...@googlegroups.com.
> To unsubscribe from this group, send email to play-framewor...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/play-framework?hl=en.
>

--
Guillaume Bort

[Julien Richard-Foy]

How do you know that “foo” is a package and not a value, in
“controllers.foo.Home.index()”?
(“foo” could be an object in the “controllers” package)

[Toby M]

Thanks for this. Using the fully qualified name works perfectly.

-Toby

[Sadache Aldrobi]

What is the important difference between both?

--
You received this message because you are subscribed to the Google Groups "play-framework" group.
To post to this group, send email to play-fr...@googlegroups.com.
To unsubscribe from this group, send email to play-framewor...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/play-framework?hl=en.

--
www.sadekdrobi.com
ʎdoɹʇuǝ

[Julien Richard-Foy]

The problem is that I don’t find intuitive the way play will add the
routes package.
Consider e.g. the following controller: http://paste.pocoo.org/show/534614/
What I am supposed to expect from Play? Where will the routes be
generated? I’m not even sure it will work (see:
https://github.com/playframework/Play20/blob/master/framework/src/play/src/main/scala/play/core/Router.scala#L964).

[Manuel Bernhardt]

Hi,

I second Julien on this one - I don't find it very intuitive either
that routes are generated on a per-subpackage level rather than at a
root level. I mainly see 3 issues:
- this convention is more complex than having all routes in a "routes"
root package (where the same rule would apply in all cases and there
wouldn't be a need to think about edge cases)
- it probably makes it harder to implement IDE support
- it is one more change when coming from Play 1 which makes migration
more difficult

Manuel

[Sadache Aldrobi]

This is a bug we will look through. Thanks Julien for reporting this.

On Sat, Jan 14, 2012 at 9:48 AM, Julien Richard-Foy <j...@zenexity.com> wrote:

--
You received this message because you are subscribed to the Google Groups "play-framework" group.
To post to this group, send email to play-fr...@googlegroups.com.
To unsubscribe from this group, send email to play-framewor...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/play-framework?hl=en.

--
www.sadekdrobi.com
ʎdoɹʇuǝ

[Sadache Aldrobi]

On Sat, Jan 14, 2012 at 1:47 PM, Manuel Bernhardt <bernhard...@gmail.com> wrote:

Hi,

I second Julien on this one - I don't find it very intuitive either
that routes are generated on a per-subpackage level rather than at a
root level. I mainly see 3 issues:
- this convention is more complex than having all routes in a "routes"
root package (where the same rule would apply in all cases and there
wouldn't be a need to think about edge cases)
- it probably makes it harder to implement IDE support
- it is one more change when coming from Play 1 which makes migration
more difficult

Well having everything in the routes package makes them not directly accessible from the same package/controller. Anyway we will explore this further. 

 

Manuel

On Sat, Jan 14, 2012 at 9:48 AM, Julien Richard-Foy <j...@zenexity.com> wrote:
> The problem is that I don’t find intuitive the way play will add the
> routes package.
> Consider e.g. the following controller: http://paste.pocoo.org/show/534614/
> What I am supposed to expect from Play? Where will the routes be
> generated? I’m not even sure it will work (see:
> https://github.com/playframework/Play20/blob/master/framework/src/play/src/main/scala/play/core/Router.scala#L964).
>
> --
> You received this message because you are subscribed to the Google Groups "play-framework" group.
> To post to this group, send email to play-fr...@googlegroups.com.
> To unsubscribe from this group, send email to play-framewor...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/play-framework?hl=en.
>

--
You received this message because you are subscribed to the Google Groups "play-framework" group.
To post to this group, send email to play-fr...@googlegroups.com.
To unsubscribe from this group, send email to play-framewor...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/play-framework?hl=en.

--
www.sadekdrobi.com
ʎdoɹʇuǝ

[Julien Richard-Foy]

On Sat, Jan 14, 2012 at 1:53 PM, Sadache Aldrobi <sadek...@gmail.com> wrote:
> This is a bug we will look through. Thanks Julien for reporting this.

Actually I think in real life developers may name their Scala objects
in upper camel cases so the current Play code should work in *most*
situations.
What I wanted to point out is that the reverse routing code generation
relies on a weak convention which might not be followed in some cases,
leading to limitations. On the other hand, putting all the reverse
routing code in the root package “routes” would not suffer of this
issue.

On Sat, Jan 14, 2012 at 2:00 PM, Sadache Aldrobi <sadek...@gmail.com> wrote:
> Well having everything in the routes package makes them not directly
> accessible from the same package/controller.

Hm, why is that a problem?

[Sadache Aldrobi]

you are inside controllers.application

you want to access index, you can have to write routes.controllers.application.index (or import it) and it is even worse in Java ( you can't import packages) 

 

--
You received this message because you are subscribed to the Google Groups "play-framework" group.
To post to this group, send email to play-fr...@googlegroups.com.
To unsubscribe from this group, send email to play-framewor...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/play-framework?hl=en.

--
www.sadekdrobi.com
ʎdoɹʇuǝ

[Ben McCann]

I have to agree that it's a bit non-intuitive not having all the routes under a routes package.  There was another thread where this confusion came up.

The shorter syntax for reaching routes is nice, but IMHO it's more valuable to have a more intuitive syntax even if it is longer.  If routes was a base package so that you could access routes.subpackage.Controller.method instead of controllers.routes.subpackage.Controller.method then I think that it wouldn't be too bad.  In fact it would actually be shorter than the current syntax when accessing a route from another package.

-Ben

[Guillaume Bort]

Actually routes is not a package but an object. This way you can
reference it relatively from the Java code (while you can't use
relative packages in Java). We tried several options when we designed
the router, and this one was the most convenient. Even if I agree that
you have to follow a set of conventions (that are anyway less
restrictives than in Play 1.2)

> --
> You received this message because you are subscribed to the Google Groups
> "play-framework" group.

> To view this discussion on the web visit
> https://groups.google.com/d/msg/play-framework/-/xx5Sjg6KtVUJ.

>
> To post to this group, send email to play-fr...@googlegroups.com.
> To unsubscribe from this group, send email to
> play-framewor...@googlegroups.com.

[Mark Baker]

Just FYI I was having this problem as well!

It would be really helpful if the documentation was updated to explain this.

The only docs I can find on Template syntax in Play 2.0 is here http://www.playframework.org/documentation/2.0/ScalaTemplates

More documentation would be enormously helpful as I find I'm often hitting issues with this -- same was true in play 1.2.x as well in fact.

Have I missed some vital link to really good documentation, or does it not exist?

Thanks,

Mark

> To post to this group, send email to play-framework@googlegroups.com.
> To unsubscribe from this group, send email to play-framework+unsubscribe@googlegroups.com.

> For more options, visit this group at http://groups.google.com/group/play-framework?hl=en.
>

--
Guillaume Bort

[Alex North]

+1. A documentation example of a controller in a sub-package would stop this question coming up (I'm here after having the same problem).

[J. O. Meyer]

I just added a note on routes subpackages to the Java documentation in the section on reverse routing in the Wiki, because I stumbled over this one as well.

Hope that's ok with everyone.

Somebody else should maybe do the same for the Scala side. I'm not a Scala guy (yet).

Cheers,

J.