DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
  1. DZone
  2. Coding
  3. Frameworks
  4. Hidden Features of the Play Framework Routes File

Hidden Features of the Play Framework Routes File

Wayne Ellis user avatar by
Wayne Ellis
·
Jul. 18, 11 · Interview
Like (0)
Save
Tweet
Share
7.86K Views

Join the DZone community and get the full member experience.

Join For Free

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/

Play Framework Framework

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • Do Not Forget About Testing!
  • What Java Version Are You Running? Let’s Take a Look Under the Hood of the JDK!
  • Cloud-Based Transportation Management System
  • How To Validate Three Common Document Types in Python

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: