Warning migration to Play 2.7

Play Framework
1

Hi there :slight_smile:

I migrated my projects to Play Java 2.7 (from Play Java 2.6), but now there are some warning in the twirl templates that I don’t understand.

From the compiler

[warn] /***/login.scala.html:70:27: method requestHeader in object PlayMagicForJava is deprecated (since 2.7.0): See Java Http Context Migration27 - 3.0.x
[warn] @CSRF.formField

But from the javadoc: Java Csrf - 2.7.x

@form(scalaguide.forms.csrf.routes.ItemsController.save()) {
    @CSRF.formField
    ...
}

How can I get rid of these warning? Do I really have to send a “Http.Request” object from each of my controllers to my templates?

Thanks,

[EDIT] By the way, following the link in the warning redirects me here: playframework .com/documentation/fr/2.4.x/JavaHttpContextMigration27 (limited to two links per messages) which is a 404

2

I just did a Play 2.7 migration from 2.6 as well.

Basically for those warnings you need to do one of the 2 things.

  1. Pass an instance of Http.Request direct into the template.
  2. For PlayMagicForJava, you need to pass things like Request or Messages as an implicit parameter like this @(names: List[String])(implicit request: Http.Request), and in Java land, the request parameter in this case will just be another parameter you’ll need to pass in. The warnings should just go away if you do that.
1 Like
3

Thanks,

So what you say is that I have to send a request parameter to my template if I am using play java?
It’s quite annoying. in coding style it’s more a regression than otherwise…

But if there is no other solution, I’ll do it this way

4

For PlayMagicForJava, there’s simply no other solution, since implicit parameters don’t exist in Java. But if you want to access request data yourself, you can always create your own ThreadLocal<Http.Request> and use that.

5

Hey @Flo354,

This is a way to make things more readable and explicit to developers. If your template needs to access the request for some reason, then it makes sense that you pass the gets it as a parameter. I think that we will eventually provide ways to pass the information the view need (in this case the CSRF token) directly, but overall, the idea is to remove some of the APIs that were too hidden and then too surprising when things didn’t work as expected.

Two things we can do to help here is to pinpoint better where at the migration you should look for that specific warning. The other one is to make it more explicit at the CSRF docs that you now need to pass an Http.Request. Do you have time to submit a PR to address these issues?

Best.

6

Hi @marcorspereira,

Thanks for your time. No problem for me to make a PR. But before that, there is something weird.

@CSRF.formField(requestParam) for instance takes only a play.api.mvc.RequestHeader, while in Java we are working with play.mvc.Http.Request.

So when I send my request object to the twirl template, I have again one operation to do: @CSRF.formField(request.asScala).

Would it be possible to add a function that takes also our play.mvc.Http.Request object? (for formField, getToken)

7

Hum, that is odd. Here is the (compiled and tested) example that we have in our docs:

As you can see there, there is no need to call asScala, and that is because Play provides an implicit conversion between Http.Request and play.api.mvc.Request:

And this should be imported by default in your templates:

If this is not happening, could you create a small project that reproduces the problem?

Best.

8

Ohhhh, I understand now.

When I import the request as an “implicit” parameter, I don’t have to give it in parameter of the other function.

So @CSRF.formField now doesn’t use the deprecated API. I thought that I had to use @@CSRF.formField(request) (which doesn’t compile)

[error] found : play.mvc.Http.Request
[error] required: play.api.mvc.RequestHeader
[error] @CSRF.formField(request)

So ok, I understand now, thanks for your help!

1 Like