CSC/ECE 517 Fall 2014/ch1a 1 sj: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
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
  • Native Scala Support
  • Migration from Apache MINA to JBoss Netty
  • OAuth and HTTPS support
Play 2.0 March 2012
  • Native Support for Java and Scala
  • Asynchronous programming support by inclusion of WebSockets and Comet
  • Built-in relational database access libraries such as Ebean, JPA and Anorm
Play 2.1 Februrary 2013
  • Migration to Scala 2.10 API
  • RequireJS support
  • New Scala JSON API
Play 2.2 September 2013
  • Improved Java Promise API
  • SBT 0.13 support
  • Built in Gzip support
Play 2.3 May 2014
  • Introduced Activator command
  • Support for Scala 2.11
  • Custom SSL Engine for HTTPS
  • Upgrade to Netty 3.9.3

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.

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 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.