Is there a way using Java to not pass Messages and RequestHeader to every page that has a form or messages inside ?

[DoomAngels]

I'm working to update our current version of play framework actually using 2.7 with a ton of deprecated warning and want to update to 2.8.
The modifications I realize I have to make is to have request as a parameter in all methods and routes, and for views call with messages ( all pages use messages ) and a RequestHeader parameters for every page that uses a Form.

Is this the right way to do it?
Is there another way to no have to pass these three things apart from all out extra parameters ?

[mkurz]

You should be able to inject components you need into your views with @this(trc: TemplateRenderingComponent).
Except the request, you can not inject it, you always need to pass it on from the controller.

[MihaiBeigar]

Sorry for taking so long to answer.
So what I should do in the templates is @this( Messages: play.api.i18n.Messages ) so I don't get the nasty deprecated error:

method implicitJavaMessages in object PlayMagicForJava is deprecated (since 2.7.0): See https://www.playframework.com/documentation/latest/JavaHttpContextMigration27

I tried this and I get another error:

CompletionException: java.lang.IncompatibleClassChangeError: Expected static method views.html.mypage.render(Lmodels/pages/mypage/MypageData;)Lplay/twirl/api/Html;]

The only thing I did is to add @this(...):

@this(Messages: play.api.i18n.Messages)
@(myPageData: MyPageData)

[bagus1]

I also am trying to upgrade and update messages. This documentation has me adding the request as a parameter:
https://www.playframework.com/documentation/2.8.x/JavaI18N#Use-in-Controllers

But then my routes have to have it:

PUT           /test/:id/test                                       controllers.Tests.test(id: Long, request: play.mvc.Http.Request)

And then I get this:

No QueryString binder found for type play.mvc.Http.Request. Try to implement an implicit QueryStringBindable for this type.

I'm not sure what that means. And it seems like it shouldn't be necessary to pass in the request from the routes like this.

Any help?
Then I do this. Think this will do it?

            Messages messages = this.messagesApi.preferred(request);
            String message = messages.at("rss.error." + e.type.name());
            return badRequest(message);

[MihaiBeigar]

From what I know in 2.8 we have to pass the request in every route because play has become really stateless ( before they saved things in the context ).
I have some methods where I could test but with GET and POST and it works properly for me, maybe PUT is the problem ?
Also in some of their examples in the web page they use request: Request instead of fully qualified class, maybe that would fix it ?

For the rest of using messages I think that is the correct form, in my case I have to pass the Messages to the view and load everything there but the aproach would be the same.

[shanness]

It's so unfortunate that Play removed the context and royally screwed up Java users. I can completely understand why they did it for Scala users (with implicits), but as it says on the migration page :-

"play.mvc.Http.Context is a crucial part of Java HTTP & MVC APIs, but it is not a good abstraction of how these APIs should work."

Yes indeed, it is a crucial part of java http and MVC apis. And you lead with that, and then just remove it.

When I first started my startup I spoke (face to face) with two of the Play developers about how second class their Java support seemed. That was bumped up the chain to Lightbend. But this just goes to show the same thing..

I'm going to have to stick with 2.6, and pray that Java gets implicits one day. Until then, I don't want to pollute my whole stack with Request arguments just to be able to access the (heavily customised and heavily used) context which we heavily rely on :(

It seems to me (from research) that you've dramatically lost lots of java users because of this change..