指南, 教程 & 参考手册
A Play application follows the MVC architectural pattern applied to the web architecture.
This pattern splits the application into separate layers: the Presentation layer and the Model layer. The Presentation layer is further split into a View and a Controller layer.
In a Play application these three layers are defined in the app directory, each one in a separate Java package.
A Controller is a Java class where each public, static, method is an action. An action is a Java entry point invoked when an HTTP Request is received. The Java code from the Controller class isn’t really object oriented: it’s mainly procedural code. The action method extracts relevant data from the HTTP Request, reads or updates the model objects, and sends back a result which is wrapped into an HTTP Response.
The domain model object layer is a set of Java classes using all the object-oriented features available from the Java language. It contains data structures and operations on which the application operates. Whenever model objects need to be saved to persistent storage, they may contain some glue artifacts like JPA annotations or SQL statements.
Most of the application views are generated using an efficient templating system provided by Play. The Controller gets some interesting data from the model layer, and then applies a template to decorate these objects. This package contains HTML, XML, JSON or other template files with special directives used to dynamically generate the model representation.
The Play framework is fully stateless and only request/response-oriented. All HTTP Requests follow the same path:
The following diagram summarizes the HTTP Request path:
The layout of a Play application is standardized to keep things as simple as possible.
This directory contains all executable artifacts: Java source code and view templates.
Where are my .class files?
Don’t look for compiled Java classes. The framework compiles the Java source code at runtime and only keeps compiled classes in a bytecode cache under the tmp directory. The main executable artifacts in a Play application are the .java source files, not the compiled classes.
There are three standard packages in the app directory, one for each layer of the MVC architectural pattern. You can of course add your own packages like for example a utils package.
In addition, the views package is further organized into sub-packages:
Resources stored in the public directory are static assets and are served directly by the Web server.
By default the /public directory is mapped to the /public URL path, but you can easily change that, or even use several directories for your static assets.
The conf directory contains all configuration files for the application.
There are two required configuration files:
If you need to add some configuration options specific to your application, it’s a good idea to add more options to the application.conf file. Configuration options in this file are read programmatically with Play.configuration.get(“propertyName”).
If any library needs a specific configuration file, try to file it under the conf directory: this directory is included in the Java ClassPath.
You can add additional configuration files to the Play configuration by specifying a file name in application.conf as the value of a configuration option that has @include. at the start of the key. For example, if you define additional MIME types in a conf/mime-types.conf
# Web fonts mimetype.eot = application/vnd.ms-fontobject mimetype.otf = application/octet-stream mimetype.ttf = application/octet-stream mimetype.woff = application/x-font-woff
you can include them by adding the following line to application.conf:
@include.mime = mime-types.conf
This directory contains all standard Java libraries needed by your application. They are automatically added to the Java classpath.
There are no compilation, packaging or deployment phases while working with Play. However Play implements two distinct environments: DEV mode during the development phase and PROD mode when the application is deployed.
About DEV/PROD modes
You can run an application either in a DEV or PROD mode. You toggle this mode using the application.mode configuration property. When run in DEV mode, Play will check for file changes and will handle hot reloading if necessary.
The PROD mode is fully optimized for production: Java sources and templates are compiled once and cached for multiple uses.
Java source code is compiled and loaded at runtime. If a Java source file is modified while the application is running, the source code is recompiled and hot-swapped into the JVM.
If a compilation error occurs, the exact problem is displayed in the browser (in DEV mode only).
Template files are hot-compiled and hot-reloaded too.
When you run the application in DEV mode, you can connect a Java debugger to the port 8000.
For example, using the NetBeans debugger:
Continuing the discussion
Now that you’ve seen what a Play application is, let’s see how HTTP routing works. The Router is in charge of translating incoming HTTP Requests into actions.