ObjectivesAn 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 JobIn 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 RequirementsIn 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.
|
|