Phase 3c

Due Date: see roadmap

Objectives

An understanding of web application architecture and technologies:
  • Page-centric versus code-centric dynamic content generation
  • Web presentation concerns and patterns
    • Model-view-controller (MVC) architectural pattern
    • controller patterns
    • view patterns
  • Web application frameworks
  • Templating, layout, and decoration concerns, techniques, and frameworks
  • Internationalization
  • Declarative versus programmatic authentication
  • Testing of the web tier
  • Play framework (including Twirl templates)

Your Job

In this phase, you will complete the application that satisfies the functional requirements by adding a web-based user interface layer to the layers developed in phase 3a.

The following additional functional requirements apply: 
  • The application should use server-side validation to validate form input data.
  • You are required to include email notification. Please refer the mailer directory in this repo.

Nonfunctional Requirements

In addition to all nonfunctional requirements from prior phases, the following nonfunctional requirements apply:
  • The application must use the Play 2.x framework for Scala (or, by instructor permission, an alternate web application framework) as intended, that is, following a proper MVC architecture where communication among models, views, and controllers is via the framework's designated mechanisms.
  • The application must use suitable Scala mechanisms to manage all components.
  • There must a minimum of embedded Scala code in the Play/Twirl page templates. 
  • There should not be any hard-coded text in the views. All static text content should be externalized (defined in a resource file). See also i18n in Play.
  • There must be a clean separation in the views between global layout concerns and specific content view concerns.
  • The application must use declarative validation to validate form input data (on the server side).
  • The application must perform authentication and role-based authorization as a cleanly separate concerns. You may use standard Play security for both concerns, or only for authentication along with Deadbolt 2 for authorization.
  • Automated unit tests must be provided using specs2 (see also here).

Additional Suggestions

  • The numguess-play-scala and todolist-play-scala examples illustrate most of the nonfunctional requirements stated above.
  • The various additional examples provided with Play itself should be quite helpful as well.
  • The struts-example.war included with Struts illustrates programmatic authentication (discouraged) within the Java Servlet API.
  • The Auth example illustrates declarative authentication within the Java Servlet API.
  • More of our own Play-based examples will be available soon.
Comments