Friday, May 27, 2011

The Javascript Bigot

Why am I a Javascript bigot?  Good question and my introspection my adversity led to an evaluation of coding practices and frameworks......

Javascript in and of itself is not bad, but I see a lot of web applications where Javascript has gone way beyond simply adding a rich feel to web applications.  When Javascript is used to control and orchestrate application behavior that's where things go off the tracks.  A lot of this is due to marshalling frameworks.  For example, you have the Order and Order Item data relationship.

I have seen lots of examples where the data is "flattened" to send it back to the client.  Initially this was done to save bandwidth (think old dial up days).  So instead of sending every order item along with the order, you may have sent an order item id and let the client ask for the order item by id later.  The reduction of the payload leads the client to have an intimate understanding of the data relationships and their implementation on the server side.  The client must orchestrate the requests for data in a way that makes sense to the server.  This leads to a distributed set of logic, multiple maintenance points, fragility and difficult testing.

Examples of this are sending data over XML where data relationships that exist on the server are not represented in the data sent to the client.  I've seen similar with JSON payloads.  DTOs used in Swing applications, Smalltalk models, Spring Beans and JSF backing beans.  If you look at web applications as basically taking data from a database and formatting it so it is pretty for the user, allows them to view and interact with the data, and save their changes -- then the closer the client model is to the persistence model, the less confusion and rework there is.   Keeping client and server models as 2 separate things leads to duplicate maintenance and ultimately multiple sets of logic and orchestration.  One of the reasons I really liked JSF and Seam is the close relationship of the server persistence model to the client model.  It leads to bean validation where the client can use the server validation rules.  It leads to expression language use of the server model within the page rendering engine.  It leads to a client that simply formats data, allows the user to interact with it and save their changes.  Perfect.

So maybe I'm not a Javascript bigot after all.

ASP .NET MVC 3

I've recently been going thru the FREE .NET training from pluralSight available at http://www.asp.net/mvc.

The training shows you how to download free versions of Visual Web Developer, IIS and SQL Server for development purposes.  There are 10 classes, each about 45 minutes long and they take you thru basic tool setup, simple web application development, the MVC framework, Unit Testing with NUnit and .NET Entity Framework (Code First model).

I am struck by the similarity between .NET MVC 3 and Spring framework 3.

Request Routing
Both frameworks route requests based on the URL.  For example a url with /Home/Search will route to the HomeController (*Controller added by convention) and the Search method within the controller.  Methods can be annotated to determine different variations for http get versus post.

Parameter Marshalling
Parameters required by the method (e.g. Search( String term)) will be gleaned from the post body or the url parameters and automatically marshalled into the method.   Even complex types like Customer will be automatically marshalled.  This is nearly identical between .NET and Spring.

Model Validation
Spring uses the @Valid annotation on method parameters to automatically invoke model validation or it can be programmatically initiated.  .NET allows programmatic initiation.  Model errors are added to the ModelState and the form redisplayed via return View();  The delivered javascript libraries from Spring and .NET (both JQuery based) display the errors on the correct place on the form.  Spring also has jsp tags to process the model errors which is better I think, as it is less javascript on the client.  Similarly, .NET allows client side validation to be turned off and let the Razor engine put model validation errors where they belong.

Model Composition
Once inside the controller, persistence processing (add/update/delete/select) can be done and a new Model can be built for use by the next view.  The model and view are combined and returned as a result of the controller method.  For example -- return View(model); or return JSONView(model);  The page template is selected from the origianl URL, for example /Home/Search will route to the HomeController.Search method and return the /home/search.cshtml page with the model injected.  The cshtml uses the Razor engine to take the model and put it's attributes on the form, much like Spring's JSP binding.

Entity Framework
Spring will use JPA/Hibernate whereas .NET can use the EntityFramework.  Both have annotated mappings of entity attributes and relationships that are very similar.  Both have the notion of an entity manager that will take care of persisting data changes without the programmer needing to be worried about connection pools and the like.  Both allow validation annotations such as required, regex matching, min/max, etc.  Both allow extension to provide your own validation rules.  Searching is performed via LINQ in .NET and JPA Criteria API in Spring.  Both use a similar idea of creating a Query using a QueryBuilder that you add .From, .Where, .And, .OrderBy clauses and the like.  The entity framework takes care of translating the query to the particular database dialect you are using and issues the query, gets the result/s and marshalls them into the appropriate entity classes.

Overall, I have really been amazed by how similar the two frameworks are.  I've long been a JSF developer and feel that JSF kicks JSPs butt.  However, if I want to be skilled in a way that allows me to develop for .NET and Java, the Spring and .NET MVC frameworks really position me to do just that with a marginal amount of re-training.

Sunday, May 15, 2011

Potential Project

One potential project may be to take the cabin finder application and port it to run on MongoDB with JBoss 7 as a container.  Then run in on Amazon EC2.  Then hook up an android UI.

To get started we could use Seam forge with the already built JPA entities for the cabin finder application.  Forge can create a JSF UI for us and a deployment to JBoss AS7.  We could tweak the UI to use primefaces and google maps widgets.  JBoss Tools 3.3 will help us with cloud deployment.  Then we could dive into MetaWidget a little bit to get an Android UI to work with it.

So while it may seem like a circuitous route to get there, I think a bit more diving into Seam Forge and Metawidget is the first order of business.  If we can accomplish our goals thru them with as little code as possible, then maybe we're on the right track.

To get started I'll download AS7, Eclipse Indigo and JBoss Tools 3.3.

JBoss Tools: Install thru eclipse add new site: http://download.jboss.org/jbosstools/updates/nightly/trunk/

Unzip Indigo and JBoss AS7.  Fire up eclipse and setup the JBoss 7 server.

Thursday, May 12, 2011

Seam Forge -- Scaffolding and Metawidget

I spent a couple of hours going thru Keon Aers excellent posting about Seam Forge (http://community.jboss.org/en/tools/blog/2011/05/11/have-your-cake-and-eat-it-too-forge-tools).  Seam Forge is similar to Spring ROO in that it has a console in eclipse that helps you create mavenized projects that use JPA2 and allows scaffolding of different view technologies.  Forge uses MetaWidget (http://metawidget.sourceforge.net/index.php) which has out of the box scaffolding for JSF, GWT and Swing among others.

It took me a few extra minutes to sort out 64-bit windows problems with JBoss Tools.  I needed to download Indigo 32-bit to get JBoss Tools to install at all.  I have not figured out how to force eclipse to run in 32-bit jvn just yet (the -vm setting in eclipse.ini causes jdk 32-bit to crash), so for now I can't use the JBoss visual editor.

It would be nice to have/build a Wicket metawidget.  I am also interested to experiment with reverse engineering a project from an existing database and/or adding forge scaffolding to existing jpa2 entities (for example change my cabin finder as an android application).

Wednesday, May 11, 2011

Future Projects?

At last posting I had been working thru a Cabin Finder application that used GitHub, JEE6 (JPA2, CDI and Weld), JSF2 and Primefaces.  I run the application in Glassfish and had attempted to host it on Google AppEngine (varying degrees of success).  I used Arquillian container based testing and Apache Derby for the database (BigTable for GAE).

The application loads data (geo information and reviews) from Yahoo Local Search based on keywords and zipcode, and plots them on google maps with info bubbles to show more details.  Since I was primarily concerned with cabins in Hocking Hills Ohio, I loaded up ~150 cabins and lodges and then pulled amenities from a static html site.

I used the application to find a cabin for our Men's retreat this year and it worked out well.  Our target cabin was booked so I was able to find another in the same area with the desired amenities.  We booked the cabin and it was better than our original target cabin.  So that was good.

Now I need to forge ahead and work thru some other technologies and want to build on the cabin finder.  Here are a few ideas for future enhancements:


  1. Hook up gitHub, Arquillian and Hudson for CI which is sadly lacking from the app.
  2. Use JBoss7 (CDI 1.1 update).
  3. Use a no-sql database (either CouchDB or MongoDB).
  4. Create a different UI using Wicket, GWT or .NET
  5. Cloud based ??  EE7 spec updates for multi-tenancy and jax-rs.
  6. Use JBoss Seam 3 and Seam Forge and re-create the app.
  7. Mobile app (either Android or IPad iOS)
That's a lot of projects to investigate, I need some help narrowing down the list.  What do you find most interesting?  Using GitHub maybe we can learn together?

Vote on the poll to the right  ======>