Last time I took software engineering, Wicket was the framework that was used. I definitely had some trouble understanding the Wicket way after coding HttpServlets. I had particular trouble with parameters. I was trying to hard to figure out how I can bind a form request to the Java as that is all done manually in a HttpServlet. With my experience with other web frameworks, I had an easier time creating the TodoList with the Play Framework.
Plain Old Java Objects
Just like Wicket, POJO has an important role in accessing the state of the web app. For example, Play and Wicket automatically binds HTML form values with its corresponding Java object. No more fussing around with HttpServlet various scoped variables or JSP Java Beans. I really like to use Java objects as they were meant to be used rather than wrapped in some JSP tag.
URI Routing
Whereas Wicket’s URI routing can be either implicit or explicit defined, Play’s URI seemed be explicitly defined in the router file with a corresponding HTTP action.
With my experience HttpServlets, I wondered how this will impact its ability to scale as changing a Servlet URI needs quite a few lines of code changes. Fortunately, I see that the view code references a route’s Java definition rather that the URI itself. Now it seems that any route changes in the Application object needs to be propagated in the views. If only Eclipse would refactor the references in the scala view code as well as it refactors the Java code…
Error Handling
When I first started my app, I was greeted with the error that the database needs evolution. I am used to Wicket returning some cryptic error message or HttpServlet returning a stack trace. I never expected to see a button that would allow me to apply a database evolution! The developer must have spent quite some time with error handling for the messages to be this clean and formatted. With Wicket or JSP, I usually have to enlist the help of Google to figure out how to solve my problem.
Play Framework
This framework seems to have much promise with creating a web app with a little bit of code. Although Play does not match Wickets’s clear separation of view and controller code, the scala implementation makes it really easy to understand how a web page will be rendered. For example, Play makes it really easy to visualize a list of objects using the @for scala function rather creating a Wicket Java list object with its associated ID in the html view.
One minor problem I have with this framework is that the developer must stay true to Play’s conventions. For example, the TodoList application’s routes are all static methods defined in the application class. There are no external constraints that will force a developer to place routing code in the Application class. Let’s hope the developer has some engineering ability when developing the application or the routing can become uncontrollable quickly.
Bret K. Ikehara 