cookies and code

Recently I was tasked with migrating a version of PHP web services to our new and growing Java stack. I had to maintain the current XML interface over HTTP but use our Java services behind the scenes to satisfy the requests. In an effort to make things easier on myself, I decided to use Grails because we were using a fairly typical Java stack of technologies (Spring, Hibernate, JUnit, etc.) that integrate extremely well with Grails’ underlying architecture. Basically, I had everything I needed in terms of persistence, domain, validation, etc in our existing stack, I just had to use Grails to expose it with a specific XML interface. Now that the proof of concept phase is complete for the project, I figured I’d share some of the niceties and challenges I encountered while approaching this problem with Grails.

First off, the expressiveness of Groovy as a language (I used 1.6.3) made the biggest task of mapping a very rigid, existing XML interface to our internal domain much easier and shorter than if I would have written it in Java. The messages were basically a flattening/expanding of our internal object graph with a couple of really quirky translations of data. Being able to treat literals as objects and the use of collection operators (*.) and methods (collect, each, find) saved me quite few lines of code. On the testing side of things, strictly from the perspective of Groovy, the as operator just kicks ass. Since mapping these interfaces was my focus, I didn’t find the need to mock too many expectations from our services, so stubbing out dependencies using maps and closures made testing SO much easier. I did find a down side to stubbing directly in Groovy however. If you are attempting to stub out a class without a no-arg constructor, you’re going to have to use a library like GMock which will allow you to create a stub passing constructor arguments. I’m not too partial to play, rewind type mocking frameworks, so I was a little bummed to have to pull in another resource to test, but it got the job done.

On the Grails side of things, integration with our existing services couldn’t have been easier. We used Grails 1.1.1 for our implementation. With a few tweaks to resources.xml, I was able to reuse our entire set of bean declarations and have them injected by name into our controllers. Although, we didn’t place our Hibernate mapping files in the /hibernate folder, I was able to create my own session factory with relative ease to get Hibernate up and running. Once I had this working, I knew I could eventually take advantage of the real reason I wanted to use Grails, RESTful interfaces over HTTP. The former PHP interface implemented a Front-Page Controller for all of its services, so using URLMappings I was able to emulate index.php to the rest of the world pretty easily. On a side note, the former interface was expecting a request variable name action which Grails reserves, but using a simple closure in UrlMappings allowed me to map it as a new request variable name and go on my way. In any case, since this is a specific endpoint, I am left open to create new controllers using Grails’ REST support as we migrate away from the older interfaces. This also means, from what I understand (thanks implicit GORM support from setting up Hibernate), I can start to use xml property binding to create my domain objects and the encodeAsXml() and encodeAsJson methods to serialize those object across the wire. This is pretty huge for us and has definitely improved my opinion of working with Java as a langauge on the web. It also solidified for me that Grails has matured quite a bit since I last gave it a test run. Lastly, I have to say that I’m really digging the simplicity of functional-testing plugin. Initially I had looked at WebTest, but this plugin is much less intimidating and was dirt simple to get started with.

Let me just stop hear and say that there were quite a few challenges to bringing Grails into our stack as well. The challenges weren’t particularly due to the implementation code itself but more on the supplemental side of things in terms of testing, continuous integration, and IDE support. Coming from an existing Java code base, we already had a set of testing tools we liked based on JUnit 4, JMock, and Spring testing. This included some really productive tools we built around dbunit supporting yaml for integration testing. Currently, Grails only supports JUnit 3, so ideally test cases should extend GroovyTestCase; there is also GrailsUnitTestCase which helps out with the mocking story quite a bit on unit tests for domain classes. Having to use JUnit 3 meant making a decision to go back and refactor testing support to work with both JUnit 4 and JUnit 3 or just rely more heavily on the functional testing support in Grails. Since I was just building controllers and a couple of domain classes, I chose to rely more on functional testing. For what its worth, there is a ticket out there for JUnit4 support. JUnit4 support aside, probably one of the most detracting things from testing with Grails is the tedium involved when testing controllers. Grails will inject a MockHttpServletRequest, MockHttpServletResponse, and MockHttpSession object for use by your controllers in the test case so you check redirected/forwarded urls, what responses will look like, easily create request edge cases, etc. By executing grails test-app -integration you can quickly see what I’m talking about. The injection process is painfully slow, at least on my last gen Macbook Pro, and I feel like I am always sitting, waiting around for these tests. I could have probably thinned down my controllers a bit, but most of the cost of executing these tests was on startup of the overall run. The only other thing I would have like to seen supported is the ability to have multiple test classes for the same domain, service, controller class. The permutations of response messages from each controller action were quite numerous, so I would have liked to create a test case per controller action rather than just one for the entire controller for readability. I only had luck getting a single test case to execute following the Grails naming conventions per object.

On the CI side of things, we build our Java projects using Maven. For large Java applications, we’ve been unable to find a simpler approach to build our software than using multi-module projects in Maven. Grails’ Maven support unfortunately did not work well with our multi-module project although it looks like they’ve made some updates for a quick fix that may help. Until then, I have our project POM hacked together a bit marking the executions of the plugin myself and using the dependency plugin to create a lib directory so I can work with grails outside of Maven w/o issues. Here are some of the relevant changes I made for my POM:

...
   <build>
      <plugins>
         <plugin>
            <groupId>org.grails</groupId>
            <artifactId>grails-maven-plugin</artifactId>
            <version>1.1-SNAPSHOT</version>
            <extensions>true</extensions>
            <executions>
               <execution>
                  <id>grails-clean</id>
                  <goals>
                     <goal>clean</goal>
                  </goals>
                  <phase>clean</phase>
               </execution>
               <execution>
                  <id>grails-test-app</id>
                  <goals>
                     <goal>test-app</goal>
                  </goals>
                  <phase>test</phase>
               </execution>
               <execution>
                  <id>grails-war</id>
                  <goals>
                     <goal>war</goal>
                  </goals>
                  <phase>package</phase>
               </execution>
            </executions>
            <dependencies>
               <dependency>
                  <groupId>org.codehaus.groovy</groupId>
                  <artifactId>groovy</artifactId>
                  <version>1.6.3</version>
               </dependency>
            </dependencies>
         </plugin>
         <plugin>
            <artifactId>maven-antrun-plugin</artifactId>
            <executions>
               <execution>
                  <id>copy-grails-test-results-for-ci</id>
                  <phase>test</phase>
                  <configuration>
                     <tasks>
                        <property name="report.loc" location="${project.build.directory}/surefire-reports" />
                        <mkdir dir="${report.loc}" />
                        <copy todir="${report.loc}">
                           <fileset dir="${project.build.directory}/../test/reports">
                              <include name="**/TEST-*.xml" />
                              <exclude name="TEST-TestSuites.xml" />
                           </fileset>
                        </copy>
                     </tasks>
                  </configuration>
                  <goals>
                     <goal>run</goal>
                  </goals>
               </execution>
               <execution>
                  <id>copy-grails-war-to-target-for-lifecycle</id>
                  <phase>package</phase>
                  <configuration>
                     <tasks>
                        <copy todir="${project.build.directory}">
                           <fileset dir="${project.build.directory}/..">
                              <include name="*.war" />
                           </fileset>
                        </copy>
                     </tasks>
                  </configuration>
                  <goals>
                     <goal>run</goal>
                  </goals>
               </execution>
            </executions>
         </plugin>
         <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-clean-plugin</artifactId>
            <version>2.3</version>
            <executions>
               <execution>
                  <id>clean-dependencies-in-lib-for-clean</id>
                  <phase>pre-clean</phase>
                  <goals>
                     <goal>clean</goal>
                  </goals>
                  <configuration>
                     <filesets>
                        <fileset>
                           <directory>${basedir}/lib</directory>
                           <includes>
                              <include>**/*.jar</include>
                           </includes>
                        </fileset>
                     </filesets>
                  </configuration>
               </execution>
            </executions>
         </plugin>
         <plugin>
            <artifactId>maven-dependency-plugin</artifactId>
            <executions>
               <execution>
                  <id>copy-dependencies-into-lib</id>
                  <phase>generate-sources</phase>
                  <goals>
                     <goal>copy-dependencies</goal>
                  </goals>
                  <configuration>
                     <outputDirectory>${basedir}/lib</outputDirectory>
                     <excludeGroupIds>org.grails,org.codehaus.groovy</excludeGroupIds>
                  </configuration>
               </execution>
            </executions>
         </plugin>
         ...
      </plugins>
   </build>
...

In terms of CI server integration, we use Hudson and the only hiccup I ran into was to make sure the user the app server is running as has rights to create a /.grails folder in its home directory. It would be nice to be able to run the unit and integration tests with lifecycle rather than all at once (GRAILS-4569) as well as have a goal to just run functional tests, but I know they are working on it. It looks like a lot of work has been done with this plugin since the 1.1-SNAPSHOT we were using, so I’m eager to give it another try as we add more web services to the mix.

The last hurdle I had to overcome in using Groovy and Grails was IDE support. Working with Java and Flex, I’ve come to find that Eclipse is my staple development tool. Unfortunately, working with the combination of Maven, Groovy, and Grails, I found myself continually frustrated with the Groovy Eclipse plugin. m2eclipse really didn’t help either since a Grails application directory structure doesn’t match the traditional Maven project layout. In the end I found myself just using the code highlighting and limited refactoring support in Groovy Eclipse and then command-line for everything Grails related. I’d heard a lot about Netbeans 6.7 support for Grails, so I was optimistic, but the experience was more of a honeymoon than anything else. Netbeans has great Maven support, but unfortunately Grails projects in Netbeans can’t take advantage of that support; Netbeans doesn’t seem to have project nature support like Eclipse. I found myself using the built-in context menus for the Grails commands to keep me from going out to the command line, but this was pretty much the only feature I could justify using in Netbeans. The code completion support was far from responsive. I found myself waiting almost 30s in some cases for the “Please wait…” pop-up to only find that the Groovy editor couldn’t tell me anything about my typed/untyped variable other than the defaults. The Subversion client is terrible. When committing, each file in the changeset has a drop-down box for what you’d like to do with the file (exclude, add, commit) and the default is add or commit. If you have a working copy with lots of files you want to exclude (e.g. – artifacts from a build process) you have to one-by-one exclude each file. Also, I’m not sure why but the patch command is not available from the SVN context-menu on the project or files view. I had to hunt through the Team menu under Subversion to finally find the option. Subversive and Subclipse for Eclipse are a reason enough to avoid Netbeans if you’re an SVN user, IMO. Maybe I couldn’t find the hotkey or context menu option, but there also didn’t seem to be the ability to refresh a folder on the project or files view? I noticed that Netbeans was constantly “scanning folders” to find changes on the file system but I had no manual way of just saying refresh. Consequently I had a lot of folder sync’ing issues between the file system and Netbeans in the rare case I needed to use the command line. In the end, a lot of the day-to-day niceties I had become accustom to just weren’t in Netbeans and for the way I was using it, it just wasn’t for me. I had heard really good things about the IntelliJ support for Grails, but due to a license fee, my poor experience with Netbeans, and the fact that Eclipse does everything else I need for development, I ended up just sticking with Eclipse. On a more positive note, SpringSource has released an alpha build of a new Groovy plugin for Eclipse which has some great promise. There is also talk of STS for Eclipse adding Grails support, so I’m hopeful the Groovy/Grails IDE experience can only improve from here.

Overall, despite the challenges I encountered, Grails is a dynamite web framework if you’re already working with Spring and Hibernate in your stack. I’ll acknowledge I may be a complete n00b in terms of the learning curve still, so if I’ve totally missed the boat on some of my points, please let me know so I can update this post. I’m excited to continue using Grails, especially with the newer releases coming up which will including Spring 3.0 and Spring-Flex.

Marcel Overkijk has taken advantage of the recent open sourcing of Flex to provide a plug-in for the Grails framework to expose AMF endpoints from your Grails application. The AMF end points are created via a service class in Grails. Grails, being built on Groovy, can very easily utilize any Java code, requires little work to configure, and can bundle a WAR for you with a single command. The plug-in looks really promising as does its road map which looks like it will have tools comparable to some of the other remoting packages available for Flex. This plug-in is built for use with BlazeDS, Adobe’s recent open sourcing of a subset of its LiveCycle Data Services product. Although I haven’t tried it yet (and its not recommended for production use), this is a great option to dumping a bunch of JARs into a shared Flex context or trying to setup your own BlazeDS server. Why not let Grails (and this plug-in) do the work for you? Seems like a much easier deployment option, IMO.

I’m also excited to look at Marcel’s code to see if I can learn anything to help in the implementation of an idea I had a while back regarding a Java factory for Flex to create objects from JSR 223 compatible languages using Java’s new script invocation API.

Thanks for the hard work Marcel! I look forward to messing around with the plug-in.

A couple months ago a few of us at work thought it would be worth looking into some of the newer programming languages and frameworks that have been receiving a lot of buzz. We were particularly interested in some of the productivity boosts that have been preached as a result of using these solutions. We decided to focus on the creation of a proof-of-concept (PoC) for one of our major web sites (sort of a stripped down CMS solution). The PoC consisted of two implementations, one using Groovy and Grails, and one using Ruby on Rails. On the Ruby side of things, we decided to look into JRuby, rather than the MRI or Rubinus implementations, since the majority of our development efforts rely on the JVM. Based on the success of this process, we are even open to considering these technologies as a possible replacement for ColdFusion and its assortment of frameworks that we currently use in our web tier.

I decided to move forward with Groovy and Grails in the first implementation. Its syntax seemed to be the most like Java which is what I am most comfortable with. I spent about 4 weeks learning the basics needed for Groovy and the Grails framework. From the little I’ve used it, I really like Groovy as a language. Learning Groovy was a cinch. The availability of closures, the use of builders to simplify configuration, and the emulation of formal properties using Groovy Beans are all great features. After seeing the amount of work being put into Groovy Swing integration, I can’t think why anyone would want to write a Swing UI in straight Java again; the syntax was just as simple as MXML without the markup. I am curious if any classpath conflicts would occur between dependencies in Groovy and our own projects, but I didn’t look into this any.

As far as Grails goes, I am really impressed at the work put into combining the technology stack on which the framework is based. The biggest and most notable feature I like is its tight integration with GORM. The use of GORM as the relational mapper truly makes working with the database effortless. Integration with legacy databases is fairly simple if you want to re-use your Hibernate mapping files, or if you want to do the configuration yourself in your domain classes. Because of GORM, you can approach pretty much any web application focusing solely on your object model; our shop follows this practice already as do most Java shops, so this is a big plus. On the templating side of things, I am pleased to see the work put into GSP. One of the main reasons we went with ColdFusion was because of the simplicity it provided over JSP, so GSP is a welcome attempt at change. Another feature I really like about Grails is the ability to create service classes to hook into, and expose, JEE endpoints with the utmost of ease. I didn’t get a chance to play with these, but from what I’ve seen in the plug-in section, it looks like working with JMS, SOAP, JTA, and a few other standards is ridiculously simple. Yet another feature I really enjoyed was the integration with Spring Web Flow. The scoping in Grails seems so natural; flows are very simple to construct and alleviate a lot of the hacking most developers have to put up with in the session scope. Finally, bundling an application into a WAR is provided out of the box so creating a Grails app and dropping it on your favorite JEE server is fairly effortless. From the little I got to work with the Grails framework, you can tell the team’s focus is clearly to improve Java in the web tier and they are on the right track. I know offering Spring integration is definitely a big draw for me since we use it so heavily in most of our initiatives.

Keeping in mind I worked with Grails 1.0 RC1, I did run into some difficulties with the framework. The first and biggest frustration I encountered was when working with domain classes. When I changed a domain class, while the built-in Jetty server was running, the server would attempt to reload the Spring context but just hang. As a result, I would have to take about 30s or so ever time I changed a domain class to bounce the built-in Jetty server. I’m not sure if this has been fixed since I played with it, but this really deterred me from working with Grails. One thing that I got frustrated with was what seems like a limitation in GSP. I wanted to create a view to edit a domain class which had a one-to-many relationship with another class. A pre-selected multi-select list box seemed like the perfect HTML widget to use. I was unable to find a way to automatically have GSP generate this for me. I searched the user forums, but I only found a post that said an implementation wasn’t available at that time. I didn’t search for a JSP library that may help, but maybe this could have been a viable alternative short of writing the code to render the HTML myself.

So after the Groovy and Grails experience, I dove into JRuby and Rails. Being that I scare easily at the sight of anything new, a colleague recommended Dave Thomas’ Rails book to get started; I also had other colleagues as resources to help in times of need. Since I’ve become more familiar with the Ruby syntax I must say there are some language aspects I do like. Mixins available at the language level are a lot handier than I would have thought, especially in the context of Rails. Properties and module level methods were nice to work with as well. I can definitely see where the “enough rope to hang yourself” analogy comes from however; I encountered a lot of variations on how to syntactically accomplish the same task. From a configuration standpoint, I also had to do some work to setup my environment. In the end, I had to pull down JRuby (1.03) and install the rails (1.2.6), activerecord-jdbc-adapter, and warbler gems as well as update my JDBC driver. Since JRuby is just an implementation of the Ruby language, however, I was able to use any Ruby reference, tutorial, or example I could find and had no issues.

As far as Rails goes, I was pleasantly surprised by how easy it was to get started. One of the biggest things I like about the framework is the inclusion of data migrations. You are required to interact with the database at a certain granularity but those interactions are abstracted by writing Ruby code. I’m not necessarily a fan of this granularity, but from a maintenance perspective, this is one of the best solutions I’ve encountered for managing an application’s database. I am also glad to see to see the FormOptionsHelper class. When data binding isn’t sufficient, the FormOptionsHelper class provides a lot of convenience methods to help work with select boxes. Tasks such as pre-populating a multi-select list box were extremely simple using options_from_collection_for_select. Lastly, I really liked the work done to integrate the use of REST into the framework. Working with ActiveResource seems fairly straightforward and doesn’t require as much configuration as I expected; that being said I haven’t worked much with this feature yet.

Based on my limited experience with JRuby and Rails, there were a few things of which I am wary. I haven’t looked into this much, but having two language cores available in JRuby freaks me out a bit. Without guidance or standards, I can definitely see a junior developer using Java implementations when Ruby ones are available forming a strange mixture of code. Another point to watch is the current maturity of the tools to migrate a Rails application to the JEE platform. ActiveRecord JDBC and Warbler are still under active development (although close to 1.0 releases) and it did take quite a bit of investigation to get my PoC working with our existing environment. Additionally, I don’t like ERB as a templating language. This is a personal preference, but it reminds me of PHP which I dislike for its heavy use of scriptlets; I really prefer using tag-based markup for templating. Finally, and probably the biggest thing I don’t like, is Rails’ implementation of ActiveRecord. ActiveRecord is cripplingly associated with the relational model rather than your application’s object model. A simple relationship such as belongs_to doesn’t relate to a composition relationship between a parent and child object, it relates to which tables contains the foreign key in your relational model. I designed my PoC with an object model in mind and had quite a bit of frustration, semantically speaking, trying to migrate that model into the mold for ActiveRecord. I felt like my focus was on the database for the most part and that seemed contrary to the goal of the framework.

Ok, so enough for my probably useless feedback, let me tell you what we decided to do. My personal preference lies with Groovy and Grails. The side of me that needs a solution in the immediate however, led to my choose JRuby on Rails. Let me explain. When I worked with Groovy and Grails, my learning curve wasn’t with the language, but with the framework. I found myself having lots of difficulty accomplishing tasks that I had expected to be fairly effortless. I associate a lot of these difficulties with the current state of the Grails framework. This is not meant to come off with a negative connotation, but with the perspective that Grails is the “new kid on the block” and still needs polish. When I worked with JRuby on Rails, the learning curve was with the language, not the framework. Rails met my expectations regarding the work needed to accomplish my goals (short of the ActiveRecord hoopla). Rails has the current advantage over Grails since it’s had the opportunity to be exposed to its community for 2 major iterations now. Getting an environment configured and working is a one time cost; I don’t count this again JRuby on Rails although it was easier to manage with Groovy and Grails. Additionally, running on JRuby provides us with the minimal level of Java integration that we need to re-use our existing architecture. JRuby 1.1′s focus on performance and very eminent release as well as Eclipse tooling support via RADRails are also an added plus.

So that’s the verdict from my PoC, but its not the end of my opinion. Anyone who has read this far and thinks I’m full of shit, ignore this next paragraph unless you want to flame me. I ultimately believe that Groovy and Grails will win out for the majority of users utilizing Java in the web tier. All of the arguments I have made for JRuby on Rails are based around the availability and maturity of its resources. These are arenas in which Groovy and Grails have just recently entered into competition. Groovy is quickly becoming the alternative for those in the Java community who are looking for a syntax with which they are more comfortable that brings a dynamic flare. Although it may have helped, Grails doesn’t seem to have the influence yet to cause the recent spike in popularity that Groovy has received as compared to what Rails did for Ruby. I think Java interop will also become more of an issue as people begin using languages running on the JVM. From the little I’ve seen, I really like Groovy’s approach, it feels familiar. I also think developers, like myself, are looking for re-use from the Java libraries and frameworks that we’ve relied on and with which we have experience. Grails’ tight integration with Spring, Hibernate, and other JEE standards (defacto or not) will make these approaches even simpler. It seems like since Grails explicitly chose to support the enterprise and Rails is choosing to stay out of it. I think Grails over time will have more to offer than Rails for those looking for new solutions on web that are currently using Java. Please keep in mind I’m not saying that Groovy/Grails isn’t currently ready for the enterprise (despite the FUD going around). As I understand it, many have been successful by using these technologies; I’m just saying I’m going to wait a while and see how others have been successful and learn from their examples.

In the end, I definitely think these new languages and frameworks provide a huge amount of productivity compared to how we are currently building applications for the web at the office. Tooling definitely needs some work on the Eclipse side of things, but Netbeans and IntelliJ are providing some great alternatives in the interim. I’m really looking forward to using JRuby and Rails to create our stripped down CMS application, which has recently received the green light. I’m even more excited about continuing to work with Groovy and Grails as their communities grow (and even pushing for its use in the office). Thank you to LaForge, Rocher, Nutter, Bini, and everyone else who has contributed their time and hard work into making Java on the web productive (and fun). I really see potential in the languages being built for the JVM and can’t wait to see what the future holds.

NOTE: Sorry to Jython, Django, Scala, and Lift for not including you in this PoC. For now I’ve spread my wings enough to be dangerous, and by dangerous I mean screw up enough software to retain job security. I hope to find the time later this year to do some more exploring.

Over the last two weeks I’ve been researching CMS solutions in the ColdFusion space. We have a pretty large site with a lot of content so a CMS solution seems like the right fit. I tried out FarCry, one of the popular OSS ColdFusion CMS solutions, and didn’t have too much luck. I spent another week looking at commercial ColdFusion CMS solutions and came up on products in two categories: products with very expensive licensing but fully capable and products with reasonable licensing but limited capability. On top of that the price points were over $25K for 2 server licenses and 5 users, on average. We currently have our app load-balanced across 12 virtualized servers, so licensing for most of these apps would be ridiculous.

I ended up looking at the Savvy CMS from BeSavvy and my initial impressions were that I really liked what I saw. The UI was incredibly simple and easy to use. The constructs of approvals, a built-in authorization system, and templating were available and very easy to prep for a PoC. Installation was so easy, it was sick. Unfortunately, we ran into a large wall when we had to address separating content from its presentation. For example, we wanted to store information about all our Resorts, but we may want to show it on a page as a list of resort names or on a page highlighting a single resort’s details. In the Savvy product, there was no way, short of extending the application itself (which required different licensing or consulting fees for BeSavvy to do the work) to incorporate our content types (i.e. – Resort, Amenity, Destination) and gain the benefits of all the built-in features in the CMS. We did have the ability to make hooks into Savvy that could manage content reuse if we programmed it ourselves. However, I saw this as busting out of the CMS to manage content when that is the CMS’ job to manage content. Why should I have to provide these features? On a side note, licensing for the Savvy CMS was extremely reasonable compared to the other solutions I looked into (licensing per URL, not server, and 5 users was $1350 [see their website for latest pricing]).

So being disappointed that Savvy didn’t have the capabilities we wanted, I went back to Farcry and gave it another shot. I had a few replies on my previous blog post that helped me move a little further with the PoC. I was able to get rid of the unusable library tool from my forms (had to patch the core using fixes from JIRA); with some thought, I also found a compromise between using the site tree and the custom content scaffolding. Unfortunately, we really needed Oracle to be the database for our FarCry installation and my every attempt to do so with the the 4.x beta has failed. I spent quite a bit of time on the google-groups applying patches and fixes as people had found them, but I still had issues (e.g. – adding content types via the COAPI after the installation). Additionally, finding documentation on how to use Rules in FarCry was another struggle I kept running into. The developers wiki for 4.x didn’t have anything I could reference and the 4.x developer’s guide I downloaded covered a very small example of using a rule, but not describe how rules work and the options available for working with rules. As a side note, anyone working with FarCry developer documentation is going to run into a lot of Hungarian Notation; it’s actually part of their suggested coding standards. This was a huge detractor in terms of readability for me, but that’s just my opinion. In any case, I eventually got a rule working, but the process of doing so was pretty tedious. Overall, I felt like I was jumping through quite a few hoops to get the PoC up and running (e.g. – using fixes from JIRA, running edge builds of the software, etc).

To end this story, yesterday I went to lunch with my managers and talked about the last two weeks of effort I had put into exploring CMS products and my work with FarCry and Savvy. In the end, we agreed that the quirky nature of developing in FarCry and the price points of similarly capable, and more usable, commercial CMS solutions warranted more investigation than we could allot in this PoC process. Consequently, we are going to try and kill two birds with one stone. We are evaluating other web-tier languages and frameworks as possible replacements for ColdFusion (I will go into this in another post). Because of the heavy usage of Java in our environment and the great job we’ve done separating our presentation and application tiers, we are considering JRuby/Rails and Groovy/Grails as possible options. We have a PoC going on for JRuby/Rails currently, but none for Groovy/Grails. Our hopes are to use this project as the Groovy/Grails PoC. Even though its a custom solution, we want to see if the new frameworks available “now-a-days” (Grails in this case) will provide enough productivity such that a custom solution is more easily maintainable until we can devote the time to doing a much better evaluation of CMS solutions. Additionally, if we find that this PoC works out well, we may not choose to go down the CMS path, who knows. In the worse case scenario, this custom solution can benefit from the work done in past development efforts and we devote more time to CMS product analysis when we’re ready.

I’ve got mixed feelings about building a custom solution, it really feels like a CMS is a good fit here, but for the sake of being productive and getting this stop-gap done, I think we made a good decision. I’m actually a little excited about finally getting to build a Grails app for the office. My Groovy/Grails skills are pretty lacking, so this will definitely help me get some great exposure. Here’s to diving in.

So today I noticed that my blog got way too many hits from being listed on the Blog section of TheServerSide.com. I even got a comment on the post from the project lead for Grails, which was pretty cool. So needless to say, I had Groovy on the brain on my drive home from work.

I started to think about the use of remote objects in Flex. We use Java to integrate with Flex at the office and I know it’s use with ColdFusion has been a big hit too. This got me to thinking, if Flex can support Java classes, what’s to say that it can’t support Groovy or JRuby or Jython or Rhino or whatever language that falls under the scope of JSR 223? I know Groovy and JRuby can be compiled to Java byte code so why can’t these classes be used as remote objects by Flex? I’m still new to Groovy and JRuby, but I’d assume the only obstacle to integrating the these technologies would be the Java interface exposed by these languages after compilation. Then it clicked in my head, the new javax.script package would normalize this interface to make it easier for developers to integrate. Also, if someone didn’t have Java 6 available, the bean scripting framework (BSF) could just as easily accomplish this goal. Additionally, if remote objects are possible, I have to wonder about how possible it may be to use the RemoteClass metadata to trigger the AMF gateway to play nice.

All of this being said, I’m excited about the possibility of integrating other languages, based on the JVM, into Flex. I know WebOrb has a few options available for .NET, PHP, and RoR apps but my (very limited) understanding is that those integrations are somewhat native to each language. It seems like a very simple layer of abstraction could be written to allow these compiled Java classes to be made available as remote objects in Flex. I can, however, understand why there hasn’t been that much written about the use of classes from scripting languages, based on the JVM, being used as remote objects. Lifecycle Data Services or CF server are required to use remote objects in Flex, from what I understand. I would assume that web services, SOAP and REST-based, are the preferred choice for users of open-source Flex in terms of integration.

Maybe there will be some interest in this topic; maybe Adobe already has adapter built (I didn’t Google that much about the topic as of yet) to address these concerns. Who knows, maybe I’ll get off my tail and actually write some sample code that solves this problem. In any case, out of the box support for any of the scripting languages supported on the JVM would definitely be a cool feature in Flex.

Ok, I’m a ColdFusion/Java programmer. I like ColdFusion for the web-tier, but sometimes I feel its way to verbose. I like Java for the application tier but I’m not a fan of static typing and some of the things that Java brings with it (i.e. – checked exceptions). I’ve been hearing/reading a lot of cool stuff about dynamic types in .NET, all of the cool stuff that Ruby can do, and how Smalltalk has had similar features for years now. With all of the press things like JSR-223 and the DLR have been getting, I figured it was time for me to start learning some new things (I will somehow figure out how this will lead to less responsibility later).

So I looked at JRuby for a little while and got too intimidated to learn a new syntax and new language constructs. This may seem silly, but I’m afraid of everything. So in the spirit of trying to learn too little at once, I started to look into Groovy. Dick Wolf from the Java Posse is always talking about it, so I figured, maybe its an easier transition for my Java syntax mind. After doing a few tutorials and playing with the console that ships with it (cool little Java app), I got pretty comfortable, pretty fast. The syntax is based on Java with, what my Ruby friends (Tan and Dyler) would call, syntactical sugar available to make things like file IO, regular expressions, database connectivity, and collections much simpler. The availability of closures alone just made it that much easier to get into Groovy. Groovy also has the notion of formal properties so that was nice too. Oh, and Groovy is written entirely in Java and supports JSR-223 so bi-directional Java/Groovy integration is really straight forward.

In any case, after a few walkthroughs, I wanted to get some instant gratification, so I tried out Grails. Now one of the first things I noticed about Grails which was a disappointment, but not a big deal, was how slow the generation tools were. Even though you are running them a discrete number of times for an application and its just to get started … slow. Now that being said, wow this is a cool framework. I may later find that’s its not all that great, but what I thought was cool about it was I understood the technologies used to build it! The build tools and generator tools are coordinated from Ant using Ivy for dependency management. The web server that comes bundled with each app is Jetty. The framework uses Spring WebFlow as the foundation for “wire framing” the site’s paths and routing. Spring is available for use with your Java classes (and I think Groovy classes as well). The GORM project is a wrapper around Hibernate 3 that Grails uses for its scaffolding (instead of ActiveRecord as in Rails). I thought it was also pretty cool that Grails uses closures as the foundation for its framework, rather than the extension of a set of base classes. Additionally, there is a notion of services which they advise using to implement business rules, so extending an existing Java SOA would get a cinch.

Some more cool stuff about Groovy and Grails, an Eclipse plugin exists that has some helpful IDE features, the generator tools generate IDE metadata so any Grails project can be imported into Eclipse, IntelliJ, or Netbeans, and Groovy and Grails both have lots of documentation to read through. I was able to get a scaffolded site up and running and start messing with the Spring and Hibernate mapping files (for fun) in under 5 minutes.

Groovy is 1.0 and Grails is at 0.5.6, so I’m not sure if its something we could begin using at work, but it feels much more natural to bridge the Java gap than JRuby, learning curve and all. As I mess with Grails and Groovy some more I’ll try to post some code samples. Now, like a good programmer, I’m going to learn a framework before I have any real clue on how the underlying language works.