CSC/ECE 517 Fall 2014/ch1a 1 rm

From Expertiza_Wiki
Jump to navigation Jump to search

Play framework

Description

Play is modern web framework that provides support for writing scalable applications in either Java or Scala. It is an open source web framework and follows model–view–controller(MVC) architectural pattern. It mainly focuses on being stateless and non-blocking I/O which is one of the main drawbacks among its competitors like Tomcat, Spring MVC etc. Unlike these, Play’s approach is not threaded, it is a framework that is based on event model. This support for a full HTTP asynchronous programming model, makes Play an ideal framework for writing highly-distributed systems while maintaining performance, reliability and developer productivity.

Play is built on Akka(Actor based model), providing predictable and minimal resource consumption for highly scalable applications. It used for handling highly concurrent systems and allows to develop applications in both Java and Scala. Play works on hot reload concept. Just save the text in the editor and hit refresh. No need to compile to reflect your changes. It also provides support for both Eclipse and Intellij IDEA

How does hot reload concept work?

In Play when you write the java source code, it is not compiled to .class files. In fact the source files are read directly at run time and compiled on the go. That is the reason, we don’t have to compile the code to reflect our changes in the application. Play automatically reads if there are any changes and if there is any exception it creates better error reports. Play has a built in functionality, JUnit ,for testing the complete functionality of application. It provides an additional functionality for Selenium tests, which are specifically written for web based applications. The benefit of using Selenium is that it will test your application in your browser and not a built in simulator.

Play automatically creates a series of files and folders when you create a new project. Let’s discuss some of the important files and folders:


History

Play Framework development started back in 2007 at Zenexity but it’s first release as a open source framework was available not available until 2009. In May 2008 the first published code for 1.0 appeared on Launchpad. This was followed by a full 1.0 release in October 2009.

Versions

===Play 1.1=== was released in November 2010 after a move from Launchpad to GitHub. It included a migration from Apache MINA to JBoss Netty, Scala support, native GlassFishcontainer, an asynchronous web services library, OAuth support, HTTPS support and other features.

Play 1.2 was released in April 2011. It included dependency management with Apache Ivy, support for WebSocket, integrated database migration (reversion is not implemented yet), a switch to the H2 database and other features.

Play 2.0 was released on March 13, 2012 in conjunction with Typesafe Stack 2.0.

Play 2.1 was released on February 6, 2013, upgraded to Scala 2.10 and introduced, among other new features, modularisation, a new JSON API, filters and RequireJS support.

Play 2.2 was released on September 20, 2013. Upgraded support for SBT to 0.13, better support for buffering, built in support for gzip and new stage and dist tasks with support for native packaging on several platforms such as OS X (DMG), Linux (RPM, DEB), and Windows (MSI) as well as zip files.

Play 2.3 has updated to include Activator, improved build environment(sbt), compatibilty with Java 8. This version of Play has been built on multiple version of Scala both 2.10 and 2.11. The WS client library has been refactored into its own library so that Play can have multiple WSClient objects, rather than only using the WS singleton. A method to use actors for handling websocket interactions has been incorporated for both Java and Scala. Anorm ( a simple data access layer that uses plain SQL to interact with the database and provides an API to parse and transform the resulting datasets) has been updated to include type safety, option parsing, error handling.

History (Include change logs - Difference between versions) https://www.playframework.com/documentation/2.3.x/Highlights21 https://www.playframework.com/documentation/2.3.x/Highlights22 https://www.playframework.com/documentation/2.3.x/Highlights23


Deploying Sample webapp/Using the Play console


Development with Play

Let us see the features offered by Play from a developers perspective, who wants to develop a web application over Play framework.

Installing Play

To install play framework, download the binaries from download page(link to download) and extract the contents to any folder. Add the extracted folder to path variable and verify whether you were able to execute the below command :

activator ui

This starts the play server and if everything goes well, you should see a default play application running at http://127.0.0.1:8888/home.

Creating new project

To create a new project just type the below command and play will take care of creating directory structure for your app with a standard layout.

activator new <app name>

If you are wondering what folders were created and what they imply, here is a brief explanation to get you started :

  • app folder: It contains the main part of the application,i.e.,models, views, controllers. All the source code is present here.
  • conf folder: It will contain all the configuration files especially the application.conf, the routes file and the messages file used for internalization (a way of adopting your application to different languages for different regions). The main entry point of the application is conf/routes file, it will contain the list of URL’s that are accessible in a application.
  • lib folder: used for extending libraries.
  • public: It used for all static files like JavaScript files, style sheets and images directories, resources which are available publicly.
  • test folder: All the application tests are written in this folder, JUnit for functional testing and Selenium tests for Web application testing.


There won’t be any predefined folder to store Java .class files, as Play doesn’t need one. It internally uses eclipse compiler and compiles Java classes on the fly. This gives the ability to reflect the changes made in Java files, without having to compile them again. Another advantage of having an inbuilt compiler is that Play will create a better error report by showing the point of failure.

How to run an application?

Navigate to the app directory and execute below command : activator run Your application will be loaded and a web server is started at 9000 port. Application can be accessed at http://localhost:9000/

Similar to Rails, Play also uses config/routes file to map the request URL to the respective controller method. A sample entry looks like this :

Get / Users.index

The above line invokes index() method in Users controller when you access the application home page.

You can either use a text editor to make code changes or even there is a support for IDEs like Netbeans and Eclipse in Play. If you want to set up a Java IDE, please check this page.

Database support

Play comes with an inbuilt Database called HSQLDB, this is an in-memory database and if you want to use any other persisting databases like Oracle, Postgres etc, you can add those configs in conf/application.conf file. Play will connect to the specified database while application startup.

Play uses 'Object Relational Mapper' to persist the model objects to a persistent DB. JPA is a Java specification that defines a standard API for object relational mapping. As implementation of JPA, play uses the well-known Hibernate framework.

Testing

To run a test case, you need to start the application in a special ‘test’ mode. Stop the currently running application, open a command line and type: play test

The 'play test' command is almost the same than 'play run', except that it loads a test runner module that allows to run test suite directly from a browser. When you run a play application in test mode, play will automatically switch to the test framework id and load the application.conf file accordingly. Check this page for more informations. Open a browser to the http://localhost:9000/@tests URL to see the test runner.

Similar to Rails, one can use Fixtures to load the test data in test. These data files reside in appname/test/ folder.

Play gives you a way to test directly the controller part of the application using JUnit. These are called 'Functional tests'.

Basically a functional test calls the play ActionInvoker directly, simulating an HTTP request. So we give an HTTP method, an URI and HTTP parameters. Play then routes the request, invokes the corresponding action and sends you back the filled response. You can then analyse it to check that the response content is like you expected.


Play Templates

Play has an efficient templating system which allows to dynamically generate HTML, XML, JSON or any text based format document. The template engine uses Groovy as an expression language. A tag system allows you to create reusable functions. Templates are stored in the app/views directory.

This template language is useful in various ways and you can read more about here (https://www.playframework.com/documentation/1.0/templates)

Play Modules

A play application can be assembled from several application modules. This lets you reuse components across several applications or split a large application into several smaller ones.

A module is just another play application; however some differences exist in the way resources are loaded for an application module : A module does not have a conf/application.conf file. A module can have a conf/routes file, but these routes will not be loaded automatically. All files are first searched for in the main application path, then in all loaded modules. Everything in a module is optional. You can create a module with the play new command, just like you do for any other application.

To load an external module, just declare it in the application.conf file of main application. One of such useful modules in CRUD module. Using CRUD you can easily configure your application to have an administration area where you can add/update/delete any model objects present in your application.

Another such frequently used module is a code coverage module based on the Cobertura tool.




Features



How popular it is? (Just specify who uses it) LinkedIn - https://engineering.linkedin.com/play/play-framework-linkedin

BBC http://en.wikipedia.org/wiki/Play_framework#Usage

Strengths and weaknesses http://www.quora.com/What-are-the-pros-and-cons-of-the-Play-Framework-2-for-a-Java-developer

? Examples ? Narration ? Hyperlinks to important terms ? References

Retrieved from "https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2014/ch1a_1_rm&oldid=85786"