CSC/ECE 517 Fall 2014/ch1a 1 sj: Difference between revisions
No edit summary |
No edit summary |
||
| Line 55: | Line 55: | ||
The '''Controller''' maps the user actions (events) to the concerned models and invokes the required changes in them. It processes the events and affects the behavior of the underlying models. Typically, in a web application, the events generated are HTTP/HTTPS requests. The responsibility of the controller is to act as a filter for the HTTP requests, process them, extract relevant information and pass it to the concerned entities. | The '''Controller''' maps the user actions (events) to the concerned models and invokes the required changes in them. It processes the events and affects the behavior of the underlying models. Typically, in a web application, the events generated are HTTP/HTTPS requests. The responsibility of the controller is to act as a filter for the HTTP requests, process them, extract relevant information and pass it to the concerned entities. | ||
[[File:Diagrams_mvc.png|frame|center|alt=A typical MVC architectural design pattern.|MVC architectural pttern.]] | |||
In a Play application, these three components are placed in the '''app''' directory, each in a separate package. | |||
'''app/controllers''' | |||
These are the Java classes that receive the HTTP requests. They are extended form the <code>play.mvc.Controller</code> class. Each HTTP request is attached to a '''action''' method. This is a public and static method having the following signature: | |||
<pre> | |||
public static void action_name(params...); | |||
</pre> | |||
Various parameters can be defined as inputs to the action methods. Play automatically maps them from the corresponding HTTP request parameters. There is generally no limit on the number of parameters to be passed and they can also be sent as query strings. | |||
Revision as of 18:16, 17 September 2014
Play Framework is a high velocity web development framework for Java and Scala. It uses the Model-view-controller (MVC) architectural pattern for implementing user interfaces. Play is based on a lightweight, stateless and web-friendly architectue written in Scala. The prmary goal of Play framework is to provide a developer friendly development platform for web development.
The major advantage of Play over other Java EE frameworks is its ability to build highly scalable applications. Its reactive model (Reactive Manifesto), thanks to Iteratee IO provides nominal consumption of resources (CPU cores, memory), a major requirement for ascendable and asynchronous applications.
Some of the major names using Play framework are LinkedIn, Klout, TheGuardian, ZapTravel and GILT
Motivation
Play framework
History
The early versions of Play framework can be traced back to early 2007 while it was being developed at Zenexity by software developer Guillaume Bort. The first full version of Play was in October 2009. Later in 2011, Sadek Drobi, co-creator of Play, joined the Play development wagon to release Play 2.0 in conjunction with Typesafe Stack 2.0.
Release History
| Release Version | Date of Release | Features |
|---|---|---|
| Play 1.x | November 2010 - April 2011 | |
| Play 2.0 | March 2012 |
|
| Play 2.1 | Februrary 2013 |
|
| Play 2.2 | September 2013 |
|
| Play 2.3 | May 2014 |
Architecture
MVC application model
Play follows a typical MVC architectural design pattern of web application development. This divides the application into two broad layers:
- The Model Layer: It handles the business logic of the actual domain problem.
- The Presentation Layer: This can be categorized into two sub parts.
- The View: It handles the actual GUI of the application
- The Controller: It maps the actions on the user interface to the concerned models.
The Model refers to the entities involved in the real world domains. It captures the actual data and applies the programming logic to it. The model operates on the raw data and adds "meaning" to it. Generally this data is stored in a persistent storage medium, like a database. Th model interacts with this data by means of a Data Access Layer which is encapsulated by it.
The View refers to the actual Graphical User Interface(GUI) displayed on the browser. This is the interface with which the user connects to the application. The data is inputted into the application using the interface provided by the view. It is usually displayed in the browser using HTML, CSS and JSON formats. It acts as the single point of access to the application for the end user.
The Controller maps the user actions (events) to the concerned models and invokes the required changes in them. It processes the events and affects the behavior of the underlying models. Typically, in a web application, the events generated are HTTP/HTTPS requests. The responsibility of the controller is to act as a filter for the HTTP requests, process them, extract relevant information and pass it to the concerned entities.
In a Play application, these three components are placed in the app directory, each in a separate package.
app/controllers
These are the Java classes that receive the HTTP requests. They are extended form the play.mvc.Controller class. Each HTTP request is attached to a action method. This is a public and static method having the following signature:
public static void action_name(params...);
Various parameters can be defined as inputs to the action methods. Play automatically maps them from the corresponding HTTP request parameters. There is generally no limit on the number of parameters to be passed and they can also be sent as query strings.