Experiences with The Play Framework

A friend of mine recommended I look at the Play framework.  It was about the same time as I had decided that using a stateful architecture like JSF/JEE was a bad fit for mobile development.  Play is a stateless architecture based on JPA and a page templating language that allows Groovy closures and Expression Language to bind to backend beans.  More control over the HTML output can be achieved when you are writing the markup as HTML to begin with, versus the JSF tags.  So I've spent a few weeks working/playing with Play, JQuery and JQuery Mobile and here are a few topics and lessons learned.

1. Test Driven Development.  Play comes with a transactional test framework out of the box.  They recognize that you must test first.  Setting up a new Play project will give you a unit test (JUnit based), integration test (HTML Unit based) and a functional test (Selenium based).  You can extend and modify them to get your own testing off and rolling.  The cobertura plugin gives you code coverage right out of the shoot also, so you can see how well you are doing with your tests.
2. JPA Extensions.  A few convenience classes extend JPA to make base entities easier to setup, and collection maintenance slightly less problematic.  The injection of entity manager into the JPA beans makes the self-reliant, i.e customer.save() will save a customer object, no need for a 3rd party manager to do the work for you.  It is critical to get this layer started off on the right foot so that you will have a nice reusable, extensible set of logic and persistence at your disposal thruout the project.  
3. Controllers and page mapping.  The routing file maps incoming requests to controllers.  Controllers automatically marshal java POJOs and can validate them against javax.validation validators.   Error messages are re-rendered back to the ui and can be global (for the page) or field specific.  Mappings can be done based on request type, i.e. GET/POST/PUT/DELETE can map differently.
4. Page markup is done by writing the appropriate view html file.  A controller method Widget.index will look for the view file widget/index.html.  Further the index method will use render(...args) to initiate the rendering and pass POJOs to the page scope.  Write up the index.html by extending a site wide template.  Then use the beans set in the page scope to bind the page to your beans.  For example, if a Customer class has a lastName attribute, the the input text field with the id/name of customer.lastName will bind to the bean when you save the form.  There's lots of good examples on the Play framework site and in the apps in the distribution.
5. JQuery.  The few JQuery plugins that I've found invaluable are DataTables, MaskedInput, TimePicker, SelectMenu and RoundAbout.  These provide my application the sortable/paginated/filterable datatables, input masks for phone numbers/dates/etc., date and time picker, select one and select many pulldowns, and a carousel for scrolling thru data.  I have found that I like to define extra attributes on the html elements that I can use in JQuery selectors to control how elements get formatted.  For instance, if I change the type of an input field to be phone, then I can select and mask all phone numbers by using '$("input[type='phone']").mask("(999) 999-9999")'. 
6. JQuery Mobile.  There's two approaches to developing pages for JQuery Mobile.  In the first method, the server will deliver an html page that has all the html your mobile site will need.  Pages are divs or articles with the data-role=page.  Hrefs can be used for this 'internal' navigation via hashtag, e.g. <a href="#pagetwo" ...  You can attach javascript to the pageinit method and call the appropriate server url to get page contents and load them dynmically.  The other option is to use 'external' page navigation where the navigation link would use an external url, e.g. <a href="pagetwo.html" ...  JQM will automatically display a loading indicator, call the server to get the page, display error message in case of problems and replace the viewable DOM.  Pretty easy but less like to work in offline mode.  I am still discovering the best options for me in this area and JQM has a good page on navigation techniques at  http://jquerymobile.com/test/docs/pages/page-links.html.
7. Cloud Deployment.  I've used Heroku for cloud deployment for the Play applications I've developed.  Heroku has native support for Play! build lifecycle, so you are essentially performing a 'git push' and let Heroku build and deploy the application.  Postgres is the default database and the application.conf file has the settings you need to deploy to postgres.  Heroku will define a ${DATABASE_URL} that you can use in the conf file to connect to the database when in production mode:
1.  %prod.db=${DATABASE_URL}
2. %prod.jpa.dialect=org.hibernate.dialect.PostgreSQLDialect
3. %prod.jpa.ddl=update
8. Amazon S3.  Heroku only gives you temporary file based storage so if you want to store images on the file system you need to goto a provider.  Heroku is using Amazon EC under the covers and there are a few plugins for Anazon S3 (super simple storage).  I used some java code posted by James Ward ( https://github.com/jamesward/plays3upload) and tweaked it ever so slightly to cache the images in Heroku temporary storage once they are downloaded from AS3 so as to avoid going to get them thousands of times at which point Amazon will begin to bill you.
9. HTML Application Cache:  In concept it's like browser cache that survives restarts.  For mobile applications it can really make a difference to have javascripts, css and images already on the device. The downside of course is how to update things when they change.  Also problematic is the 'master' page will be stored in application cache too, so if the page is dynamically generated on the server things are apt to go awry.  Still working thru some issues on this one myself, but so far the pages are usable in 'airplane' mode when I use internal JQM navigation and I get less caching issues when I use 'external' navigation.

In summary, I've found working with Play! to be straightforward.  It's nice to have a web application framework that has everything you need to develop a web application right out of the box.  I am still uncertain about reuse of page markup particularly if you have a page that will dynamically update small fragments of itself.  I have written the page and the page fragment separately and duplicated markup in both. Also, the mobile pages are really similar to the browser/desktop pages with some reformatting.  Once again the display markup is duplicated.  There's not much in the markup, but it does slow things down when you need to make the same change in more than one place.

You can download Play! and learn more about it at http://www.playframework.org/.

More about JQuery Mobile at http://jquerymobile.com/demos/1.0/docs/about/getting-started.html

See my application on Heroku at http://golfplus.herokuapp.com/

  and http://golfplus.herokuapp.com/mobile

FredHQ's Roundabout: http://fredhq.com/projects/roundabout/
DataTables.net: http://www.datatables.net
Masked Input: http://digitalbush.com/projects/masked-input-plugin
Select Menu: https://github.com/fnagel/jquery-ui/wiki/Selectmenu
Date Time Picker: http://trentrichardson.com

Mobile Applications with HTML5 and CSS3

The pendulum swings:  it seems like web application development has been a square peg in a round hole for a while now.  We want highly interactive, user responsive web applications that feel like desktop applications.  We want separation of business logic from presentation tier.  We use JSP, ASP or JSF to act as the intermediary between the client and business tiers (take in html, process and emit html).  The HTML spec was written in a request/response paradigm which is hardly interactive and responsive.  So we add on Javascript to give web sites some interactivity.  And from here the worm begins to turn......

Javascript evolved from a tool marketers could use to add some sizzle to a web site, into a full fledged framework for control of the browser.  With CSS3, you can take advantage of local hardware to perform faster renderings than the browser could do alone.  All this makes me wonder if the JSP, ASP or JSF paradigms work in mobile phone development since they are both server side templating and emission of HTML.  With more advanced HTML and Javascript specs, could the browser really BE the templating and emission of HTML tool?  Could you just use the server to accept, emit and validate data via JSON/XML or whatever?  Would that allow the browser to store the data in local cache for later use, like when you get off the airplane or finish a phone call?  If this approach is good for the phone, then why not the desktop user?  Could web applications be written using HTML/JavaScript and JSON -- with a Spring, JEE or .NET stateless service handling get/post requests?

I don't know the answer.  It seems to me that the HTML spec may be missing some necessary templating rules to make that happen, i.e it would be nice to have a site format with top/left nav and footer applied to all pages.  Wait!  isn't that CSS' job.  What about large data, like images or content from a CMS?  The browser does a good job of caching these things locally already.

As browsers advance in efficiency and capability, and W3C has finally started to move the HTML/CSS specs forward, Maybe it's time to rethink the paradigm.

MySQL Database on OpenShift

I've been working on an application for my golf club that will allow us to arrange tee times, sign up and play, and report our scores.  I want to build the application with JEE6 technologies like CDI/Weld, JSF2 and JPA2. I started using JavaDB as a database.  Then I found OpenShift from RedHat as a hosting alternative.  It allows me to build the application locally on JBoss AS7 and then publish it to my OpenShift account using Git.  OpenShift also allowed me to change the DB over to MySQL by simply installing MySQL into my account using rhc-ctl-app -a "fw" -e add-mysql-5.1.  You can also add phpAdmin to make administration of your DB easier.  Here's a good blog on setting up OpenShift, MySQL, phpAdmin and Redmine: https://www.redhat.com/openshift/blogs/phpmyadmin-your-way-into-openshift-express-database-management-bliss

 You can see the application running at http://golfplus-basinc.rhcloud.com/.  I am now working to get Google Analytics and WebMaster tools hooked up to the application.  Once that's done, I can focus on the android cell phone component.  I will be reviewing phoneGap, Sencha and Tiggr as alternatives to straight up Android SDK.

JBossAS7 and Primefaces on OpenShift

This weekend I began experimenting with OpenShift, the JBoss platform as a service (PaaS) available at https://openshift.redhat.com/app/.  I run from Windows so a Cygwin and Ruby install is required to get started.  The installation of cygwin and required modules took me about 1 hour to complete.  After that, I was up and running on OpenShift in a jiffy.   There's a good blog on using CDI/Weld on Openshift at https://www.redhat.com/openshift/blogs/seeing-cdi-working-in-openshift.

In order to get Primefaces to deploy correctly on JBossAS7 I had to upgrade to primefaces 3.0.M2.  Then there are a few markup differences between 3x and 2.2 that I need to resolve.  For instance, the theme selector needed changed in order to get any pages to work.  Also, the gmapInfo panel has some difference requirements, so I have disabled it for now.  Lastly, the dataTable instant selection is different.  It used to have a onrowselectlistener attribute, but now wants a nested p:ajax tag.  I haven't figured out how to get those to work yet either.

You can see the current JSF/Primefaces/Weld/CDI/JPA application at http://cabins-basinc.rhcloud.com/primetest/cabins/search.jsf

Using JAXRS and CDI

The following helped me out a lot when setting up jaxrs over existing managed beans.

http://download.oracle.com/javaee/6/tutorial/doc/gkncy.html

Essentially the managed bean is now stateless ejb with jaxrs annotation:

@Stateless
@Named
@Path(value = "/cabins")

the method is also annotated:

@GET
@Produces(MediaType.APPLICATION_JSON)
@Path(value = "/list")

The entity is annotated so it can be marshalled:

@XmlRootElement
public class Cabin extends AbstractEntity {

And a JaxApplication loader class was added:

package com.examples.service;

import javax.ws.rs.ApplicationPath;
import javax.ws.rs.core.Application;

@ApplicationPath("/rest")
public class JaxApplicationPath extends Application {
}

With these things in place I can reuse the CabinSearchBean from the web page site as a bean for jaxrs (json or xml) and access via Android.

EE Server versus Tomcat/Jetty

First off, I like Tomcat.  It starts fast, is a solid JSP/Servlet container and, when coupled with Spring, gives a well rounded application development framework.  However, I also like Weblogic, Glassfish and JBoss.  EE6 containers with EJB3, CDI/Weld and JSF/Facelets also gives a solid application development framework.  So what's the difference, and why or when should you use one over the other?

1. Connection Pooling vs C3PO
2. JTA vs Atomikos
3. JMS vs ActiveMQ/RabbitMQ
4. JAX-RS/WS vs Metro or CXF
5. EE Security (5 specs) vs JSecurity or Spring Security
6. EE Interceptors vs Spring Events

So it appears as though you can add in each of the EE stack specs into Tomcat as needed.  The real question becomes what is as needed and do you design your application around what's missing as much as what's there?

Lightweight
Tomcat/Jetty/Resin will all start using less memory than Glassfish/JBoss.  If however, you need connection to a database(s) (issues 1 and 2 above), asynchronous processing (issue 3), restful web services (issue 4), security (5) and loose coupling (6) then you'll need to add Spring to your web app on Tomcat/Jetty/Resin and then the startup times and memory footprint begins to look similar.

Vendor Independence
Tomcat with Spring gives you lots of configuration options.  Different implementations of JCA, JMS, Web Services, Security, Persistence can all be wired in to the environment.  This is a great advantage when dealing with existing application infrastructure where synergy to other applications is required.  As much as JEE vendors purport that the EE spec isolates you from vendor lockin, it's more difficult to perform than the color glossy brochure would have you believe.  The ability to deploy a war on multiple JEE servers does exist, so there is that level of independence, but it's generally much easier to use the vendor's chosen implementations of security, persistence, jms, etc.

Testing
Spring has a great test framework to allow testing from junit or testng without a container.  Since Spring is independent of container provided services, you can pretty easily spin up a Spring configuration in the JVM.  JEE testing requires a container.  With frameworks like arquillian, it's easier to spin up a embedded container for testing, but Spring has a definite advantage here.

Free
What a misnomer.  Often we think that because we can download a product and use it without paying, that it is free.  Well, I guess if we already knew everything we needed to know to use the product -- it would be free.  But, when you try to use the software you just download for the first time, there's usually some learning curve.  Documentation, community involvement, support and professional services can all come into play in order to get you up and running.  My opinion is that the Spring documentation is pretty good here.  The JEE documentation (link below) is good also, but note quite as polished as Spring's.  The issue with Spring, is that the variety of implementations for any of the basic services, means you will be dependent on additional vendor documentation, unless you simply use what Spring recommends.  So the vendor independence advantage may be a little diluted.

Why Use JEE
If you have a clean slate to start with, i.e. very few mandates to use a particular implementation of Security, WebService engine, etc.  Also, if you really don't care who provides your connection pooling, JMS, JCA, JTA, etc. then a JEE server will provide all of those basic services.   You have development and deployment hardware capable of supporting a reasonably large memory footprint.

Why Use Spring
You want customize and tailor the configuration of the basic application infrastructure.  You want to learn technology that is widely spread.  You want to learn technology that can be used in a variety application ecosystems.  You are severely limited in the development or deployment hardware.


references:
EE Doc: http://download.oracle.com/javaee/6/tutorial/doc/gfirp.html
Spring Doc: http://static.springsource.org/spring/docs/3.1.0.M2/spring-framework-reference/html/

Think Objectively

What does ORM stand for?  Object Relational Mapping.

What is an Object?  Data and behavior.

What is a DAO?  Data access object.

If an Object is data and behavior, why is there such a thing as a "data" access object?  Why not an Object access Object?  Does a DAO have any place in an object oriented architecture?

Good questions.  I don't pretend to have the answers, but I have a few observations.

First, if you use DAO layer, then something has to reassemble your object model from the "data" you just accessed.  Now you have a DAO, a DTO and an assembler just to get data from a database into a usable object model.  Seems like a lot of work.  Also sort of inflexible to change as we are prone to omit details from the model that we are not currently interested in, and leave it up to the next person.

Second, hibernate is a good ORM but it has a steep learning curve and a few limitations.  There is no cure for having to learn things and I get that, but it's pretty weird that the ORM market is still evolving some 35 years after OO design and development began.  It seems pretty fundamental to software development to be able to get  and store data.  JPA is a "standardized" version of Hibernate, but eclipseLink and Hibernate implementations of JPA are not simply swappable.  Don't kid yourself, Oracle wants you to use EclipseLink and Redhat wants you to use Hibernate for a reason $$$$.  They aren't going to make it super easy to change things and cut them out of the loop.

Lastly, I personally would like to think the DAO is dead (DOA).  Spring ROO manual has a section dedicated to the demise of the DAO.  JPA gives a much cleaner transition from data storage to Object model.  It's not perfect, but far better than having three or four architectural layers dedicated to getting data.  Also, I have seen applications where Object classifcation/subclassing is left out altogether in the DAO layers just because it's difficult to implement in that way.  This leads to the visitor pattern to implement object specific behavior.  Now, maybe I'm wrong but doesn't it seem like a bad idea to have a travelling section of business logic that is seperate from the actual object model?  I guess I'd like to see the visitor pattern go the way of the DOA DAO.

l8r