Porting Roo MVC Applications to Foundation

Introduction

One of the areas I have been exploring is the structure of web applications generated by Spring Roo.  These are Spring WebMVC application and result in a tightly structured application.  But the WebMVC is only part of the solution.  The add-on provides the view definitions using a nicely structured tag library and bases it's view definitions on these.  Of course part of the structure is result of Roo's code generation facilities, and that does enforce a regularity of the application structure.

Currently the rage in web design is flat responsive web applications.  At work it seems that everyone is in love with Foundation, and truly there is a lot to love about it.  It's a snap to layout forms and pages.  Prototyping is a breeze.  One can build nice looking pages without tip toeing into CSS hell.  But most importantly it is responsive allowing your application to not only look decent but to look decent on multiple devices.

Petclinic Home Page - Desktop Browser

The Spring WebMVC applications generated by Roo are nice, practical, but not responsive.  Available within Roo however there is the GWT front end that does have support for mobile.  But that again is not responsive.since mobile and desktop are separate sets of responses.  On the server side we really want to stick with being responsive so we can avoid having to inject functionality to handle multiple device responses.

As part work on another post I have been working on exploring the Spring WebMVC structure.  While working on that post I have been thinking that it wouldn't be hard to port an application to use Foundation.  So I decided to do a proof of concept on that.

Design

Petclinic on iPhone 5
(Ripple Emulator)

When the WebMVC is installed in the application it injects two kinds of assets; those that are managed such as the CRUD views of domain objects, and those that are injected during setup an under the developer management.  Most of the files that fall in the latter category is application framework (tiles defs, etc), view components (header, footer) and system views (exceptions, index).  The migration should be limited to the modification of those assets.  Ideally, we should be able to leave the assets managed by Roo alone so Roo can continue to manage them for us.

Generally in the migration we are going to want to limit changes to;

• tiles layout assets (default.jspx, header.jspx, footer.jspx, load_scripts.jspx).
• The tag library (*.tagx) files.  

And we want to avoid making changes to;

• tiles definition files,
• view files
• controllers, etc.

Results

In porting the site to Foundation the efforts focused on three areas;

• Page Layout and Navigation
• Forms and Fields
• Tables

I will dive into the fine details in future posts, but here I want to present an overview of my experience migrating the pet clinic application to use Foundation.

Page Layout and Navigation

Page layout while setting the stage for things to come was not that hard to migrate.  Fortunately the Roo WebMVC placed all the loading of the Javascript in a tag so moving it from the head to the end of the body was simple.  Most of the effort required here was not so much implementing the new layout as to finding and selecting a new design.  There are quite a few really sharp looking public domain layouts to choose from so some time on the Intenet is well worth it  After fishing around for a while I settled on using layout from the Foundation web site.

Getting the menu to run was also really simple, largely because both implementations are based on a unordered list.  So most of the effort here was changing styling and the handling of categories of menu items.

Then after a few adjustments to components here and there I got the home page working.

Then looking at the home page using iPhone 5 emulation with Ripple;

And here it is with the hamburger open;

There are a few rough areas like the footer that require more work.  But generally the result is a presentable site.  The Spring WebMVC theme handling is broken, but shouldn't be hard to fix.

One of the goals in my POC was to minimize change occurring in the vews folder.  I ended up deleting the header.jspx file, it was injecting a page wide image breaking the responsiveness of the pages.  But the changes here were anticipated.  More importantly we did not modify the index.jspx file.  Since having to make changes here would be indicative of having to make changes to all the  view files.  Something we really want to avoid..

In my next post I will look at forms and fields.