Wayne Ellis is a Software Architect. He has been developing with Java since 1998, and using J2EE since its very beginnings. Wayne is the author of Introducing the Play Framework and has written several blogs on the hidden features of Play, such as Fast Tags and Web Services, plus, Wayne is also a top answerer on the Play Framework at Stackoverflow. If you have any questions on Play, you will probably find him hanging out there! Wayne has a strong background in Web Application development, mainly using Java as the server-side technology. He is a keen technologist who loves learning new techniques and technologies. Wayne is a DZone MVB and is not an employee of DZone and has posted 6 posts at DZone. You can read more from them at their website. View Full User Profile

Hidden Features of the Play Framework Routes File

07.18.2011
| 5567 views |
  • submit to reddit

Today, an interesting question was raised at Stackoverflow regarding if it were possible to define Dev/Prod mode specific routes in the Routes file.

The simple answer, was that I didn’t know, but I had an theory that this could be possible, so I threw together a quick prototype to see if it would work.

The premise of the idea was that the routes file does allow scripting to take place, which I have used before to define a Context, which is the agreed way to for managing the war context when deploying to Tomact and other Servlet containers.

So, taking the idea that scriptlets are possible in the routes file, I wondered if this could be taken a step further, whereby logic could be carried out in the routes file, rather than simple assignment scriptlets.

The prototype

The prototype itself was pretty simple. I started a new play project

play new routesproto

and started the Play server.

play run routesproto

I then modified the Application.java to have a few actions, which simply returned a little text to show the action completed successfully. There was simply no need to write templates for the actions, as that was not what I wanted to prove.

public class Application extends Controller {

    public static void index() {
        render();
    }

    public static void noDev() {
        renderText("NoDev");
    }
    public static void noProd() {
        renderText("NoProd");
    }
}

I then went about making my routes file Dev and Prod specific. I created a few routes per environment as follows.

# Home page
GET     /                                       Application.index

# Ignore favicon requests
GET     /favicon.ico                            404
# Map static resources from the /app/public folder to the /public path
GET     /public/                                staticDir:public

%{ if (play.mode.isProd()) { }%
GET		/route1									Application.noDev
GET		/route2									Application.noDev
GET		/route3									Application.noDev
%{ } }%

%{ if (play.mode.isDev()) { }%
GET		/route4									Application.noProd
GET		/route5									Application.noProd
GET		/route6									Application.noProd
%{ } }%

*       /{controller}/{action}                  {controller}.{action}

So, what’s going on in here? Well, all the main (shared) routes are held at the top of the routes file, and then anything that becomes specific to Dev or Prod mode are placed at the bottom. As usually is the case, the catch-all should be last, so after the second if tag is closed, we follow it with the catch-all route.

The following line is responsible for the logic in our routes file.

%{ if (play.mode.isDev()) { }%

and all routes between this piece of logic, and the closing of the if statement, indicated by the following line, are enabled.

%{ } }%

This simple line simply checks what Mode the application is running in, and if it is running in Dev mode, then the routes defined in between the opening and closing parenthesis become available.

Conclusion

I do not expect this syntax to immediately find its way in to every Play application routes file, but I no doubt think that it will be useful to many of us Players. Indeed, without the Stackoverflow question, I would never have even considered experimenting whether this method was actually possible or not, so thanks to Roshan for raising the question.

From http://playframework.wordpress.com/2011/07/15/hidden-features-of-the-play-framework-routes-file/

Published at DZone with permission of Wayne Ellis, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags:

Comments

Sirikant Noori replied on Fri, 2012/03/30 - 1:21pm

This is awesome – thanks!

I won’t get an opportunity to try for some time but this idea looks like a different version of the idea could be realized that would allow domain-specific routing to be implemented.

Thus, an app deployed to a single PlayApps-shard might be able to uniquely-service multiple distinct domains that run the same app but with different branding.

Java Exam

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.