Play 2.7 Roadmap


(Rich Dougherty) #1

Play 2.7 is due in Q2 2018. Here’s a link to the roadmap we’ve come up with: https://docs.google.com/document/d/11sVi1-REAIDFVHvwBrfRt1uXkBzROHQYgmcZNGJtDnA.

If you have anything you plan on contributing to Play in that timeframe that you think is worth mentioning on the roadmap, let me know and I can add it on.


#2

Is this thread specifically for the roadmap, or also questions?

Because I have questions regarding PlayService for minimal applications(What is its intended use case, is it more ideal for ebean projects that don’t have a public facing web interface to worry about?)

And this: Support Java actions without a thread-local Context (How is this going to be migrated? It’s really useful to get URL parameters out of the request() object, which if I recall uses the thread local context, etc…)


(Schmitt Christian) #3

Well this means that instead of

public Result myAction() {
ctx().request()....
return ok();
}

one would write:

public Result myAction(Request request) {
return ok();
}

as an example, but there is still no clear api for that.
another idea was/is:

public Action myAction() {
request -> ok();
}

#4

That would be pretty cumbersome to migrate, and confusing especially since it would require adding an argument to each controller method, that isn’t actually reflected in the arguments provided in the routes file itself.

I can’t exactly tell how the 2nd example would operate.

In projects I’ve worked on, I mostly use request() as a way of detecting arguments added to individual calls, allowing for more fine-grained control over things like database queries.

A common example is providing start and stop times in the URL parameters. Those can be entirely optional. Making a separate route for no provided times, only start provided, only stop provided or both provided, seems like a bad idea when I can do it with only 1 route. And with this data, I can then dynamically add parameters to the ebean query.

They’re optional dependencies and the decision of adding them is entirely up to the user making the call. They might want a historical view of everything between 2 UNIX timestamps(provide start and stop), or they might say “I want everything of the past X hours”(provide only start).

The concept of a “context” seems logical, as each route being called(each action) is logically its own separate thing that cannot affect the application as a whole.

My main concern is: will I still be able to easily, without changing much of my code, access this data that I will unpredictably need or not?

EDIT: I just remembered optional parameters in the routes file. I probably forgot because I recall demonstrating the mere abilitty of doing request() somewhere.


(Schmitt Christian) #5

well in 2.7. it would be just another option to define your routes, you would still be able to use request().


#6

Ah ok, it will just use a different underlying system then?

I also seem to recall, but I’m not certain on this point, that request() contains the (possibly provided) language of the one calling the route, allowing for use of language-separated error messages, with the messages files.

I was just concerned because I recall request() currently being a part of the context and I was worried about losing that. Because it’s just so utterly convenient.

And I assume there will be other ways to keep track of specific data per thread, in order to avoid querying it to the database more than 1 time per route called/action.


(Greg Methvin) #7

PlayService omits sbt-web and twirl, as well as the routes compiler and the custom Play layout. Those things can be added back manually if you need them (by adding SbtTwirl, RoutesCompiler, etc.). It’s designed for situations where you want a minimal Play service, or if you want to manually add sbt plugins as you need them rather than depending on everything. This was a commonly requested feature in the past.


#8

I do recall asking “how do I disable sbt-web” a few times in the past and finding it wasn’t possible. Seems neat and I’ll certainly try it out.


(Greg Methvin) #9

@KoenDG As I understand it, the current proposal is to add an additional Request parameter to your route. So you can use this instead of using the static request() method. It’s the same Request type so the API would be the same.

In any case, the old API should still be usable in 2.7 so you’ll have time to migrate to whatever the new way is.


(Patrick Li) #10

With the new/current proposal, would you still be able to do things like below in classes other than controllers?

Http.Context.current()


(Greg Methvin) #11

Well, the new way would be to pass the Request to your controller and then explicitly pass it around to where it’s needed. For the other methods that mutate the context like those on Response, you could accomplish the same thing by manipulating the Result.

I’m sure it will still be possible to use Http.Context.current() in 2.7 though. I don’t think we should deprecate any of the existing static methods until we’ve given people a chance to try out the new API.

The main benefit here is things are much more obvious to new users. You no longer need to ask the question “can I use the context here?” because you’re not using thread local state. Everything is passed explicitly.


(Ivano Pagano) #12

What is actually meant by

gRPC client support

?

Is there any support already in 2.6.x? Where would gRPC be hooked and for what kind of purpose?

Thanks


(Schmitt Christian) #13

I think it means more integration with https://github.com/akka/akka-grpc


(Rich Dougherty) #14

Exactly. That means that Play could receive gRPC requests. There would also be an easy way for Play to make gRPC requests.