Introduction to Play Framework: Main Concepts

This article is translated from the official Play documentation. See: http://www.playframework.org/documentation/1.1.1/main

Play Framework is a Rails-style Full-stack Java Web Framework.

MVC model

The Play application follows the MVC Architecture Pattern used by the Web architecture.

It separates applications into different layers: Presentation layer and Model layer ). The presentation layer is further divided into View and Controller ).

• Model is the Domain-Specific Representation of information processed by an application ). Most applications use persistence mechanisms such as databases to store data. However, MVC does not mention the data access layer, because it belongs to the lower layer and is encapsulated by the model.
• View renders the model into a form suitable for interaction, usually a user interface. A model can have multiple views for different purposes. In Web applications, views are usually presented in HTML, XML, or JSON format, or binary charts.
• The Controller processes events and changes the model accordingly. In Web applications, events are usually HTTP requests: the Controller listens to HTTP requests and extracts data from them, such as querying string parameters, request headers, and then changes the lower-layer model objects.

Play divides the three layers into different packages under the app directory.

App/controllers

A Controller is a Java class, and its static public method is Action ). The action is the entry point for Java processing after an HTTP request is received. The Controller class is actually process-oriented, not OO. Action extracts data from the HTTP request, reads or updates the Model object, and returns a result packaged as an HTTP Response.

App/models

Model is a set of Java classes with all OO features. Contains data structures and operations available to applications. (Congestion model ). Support persistence through JPA.

App/views

The application view is generated by the Play template system. The Controller retrieves data from the Model and then presents it using the template. This package contains HTML, XML, and other template files and is used as a Representation for dynamically generating models ).

Request Lifecycle

Play is completely stateless (stateless) and only for Request-Response ). All requests follow the same path:

Application Layout

App directory

Contains all executable artifacts: Java source code and view templates. There are three standard packages, each representing a layer of MVC. You can also add your own packages, such as the example utils package.

View pacakge can be found in the molecular packages:

• TagsThe ta that stores the application. For example, reusable template fragments.
• One Controller and one view directoryBy convention, the template of each Controller is stored in its own subdirectory.

Where is the. class file?

Play compiles the Java source code at runtime and caches the compiled classes in the tmp \ bytecode directory. The. java source file for executable artifacts of the Play application is not compiled. class: including jar files ).

Public directory

Stores static resources that are directly processed by Web servers. There are three subdirectories: images, stylesheets, and javascripts.

Conf directory

Contains all configuration files of the application. Two required files are:

• Application. conf: The main configuration file of the application, which contains all standard configuration options.
• Routes: url routing rule definition file.

This directory is included in Java ClassPath.

Lib directory

The standard Java class library for storing application dependencies. This directory is automatically added to Java classpath.

Development lifecycle

When using Play for development, there are no compiling, packaging, and deployment stages, which represent two different environments: DEV mode for development and PROD mode for user deployment.

Compile and load Java source code at runtime. If the Java source file changes when the application is running, the code will be re-compiled and hot loaded (hot-swapped) into JVM. The same applies to template files.

About the DEV/PROD Mode

Use the application. mode configuration attribute to switch between DEV and PROD. In DEV mode, Play checks and performs hot loading when necessary. The PROD mode is optimized for the product: Java source files and templates are compiled only once.

Debugging

In development mode, connect to port 8000 through JDPA for remote debugging. The original article is very simple. In fact, it can be debugged remotely or locally)