IS480 Team wiki: 2012T1 One-hit Wonder Project Overview Framework

From IS480
Revision as of 18:50, 6 October 2012 by Kaili.tee.2009 (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

HomeOHW.png Home

Users24.png Team / Stakeholders

Info24.png Project Overview

Calendar 2 icon&48.png Project Management

Folder fav24.png Project Documentation

TeamRef.png Team Reflection

Res&Ref.png Resource & References



Scope & Deliverables



Framework Comparison

Spring Framework
1. Easy Configuration with Annotations and Conventions
2. Integrates with many view options seamlessly: JSP/
3. Excellent REST Support
1. Instant reload not built-in, need JRebel or Spring Roo
2. No open development process, need to be SpringSource
3. Ajax requires 3rd-party library

Struts Framework
1. Many Struts values are represented in XML or property files. This loose coupling allows wholesale changes to be made by editing a single file.
2. Apache Struts provides a set of custom JSP tags, particularly bean:write, which allows user to easily output the properties of JavaBeans components.
3. Apache Struts provides a set of custom JSP tags to create HTML forms that are associated with JavaBeans components. This allows user to get initial form-field values from Java objects, and redisplay forms with previously entered data intact.
4. Apache Struts has built-in capabilities for checking that form values are in the required format.
5. Consistent approach in terms of framework through application.
1. Steeper learning curve because to use MVC with Struts, you have to be comfortable with the standard JSP and servlet APIs and a large and elaborate framework.
2. Poor documentation and Struts has fewer online resources.
3. With Struts applications, there is a lot more going on behind the scenes than with normal Java-based Web applications. Hence harder to understand.
4. The flip side of the benefit that Struts encourages a consistent approach to MVC is that Struts makes it difficult (but by no means impossible) to use other approaches.

PLAY! Framework - Chosen Framework
1. Play is built for a ‘share nothing’ architecture (think about it as a Stateless framework).
2. It does not really rely on the so-called Java Enterprise standards.
3. Play framework enables scalability. It is usable even if you need to serve a very high traffic.
4. Play is standard Java, so any standard Java library can easily be used.
5. Manages dependencies without the need to learn the complexities of Maven

1. Unless the library you want to use relies on the Servlet API, there won’t be any problem.
2. Play 2.0 lacks the connectivity and authorization framework to interface with different social media service provider API such as Facebook, Twitter, LinkedIn and other prominent social media networks.