This is enabled by turning on controller annotations in your SecurityConfig.groovy file:

So all is now good in our project. We can secure either controllers or actions with annotations, enabling us to declaratively setup security side-by-side with the code that we’re securing in a very straightforward manner. You can continue developing your Grails applications with glee, fully assured that security is no longer an issue. But wait, one day you decide to install one of the many useful Grails plugins that add controller artifacts to your application. Lo and behold, you have no way to secure those controllers! Of course, you could descend into $USER_HOME/.grails/$GRAILS_VERSION/projects/projectName/plugins/pluginX and hack the source code for your individual instance of the plugin. This ought to work, but you’re now rather constrained in that every time you update the plugin you’ll need to remember to go make this manual change. That doesn’t sound very agile at all, does it? OK, so how about forking the plugin? This is a little bit better, but now you have the burden of merging changes from the global plugin repository to yours every time a new release happens. This is better, but still a bit cumbersome. How about becoming a committer and adding it to the global source? Of course not. Not everyone will want to secure their plugins the same way you do, and you’ve just introduced a rather unnecessary dependency on the Spring Security plugin. I say all this in an attempt to paint a grim picture. In reality, we’re actually in very good shape. Grails Filters to the rescue!

All that you need to do is create a Grails filter that will match requests to the plugin artifact in question and then delegate to Spring Security for authorization. If they are authorized, you simply return true. If not, you can direct them to your login screen. It’s this simple:

As you can see here, I’ve secured both the Blurb plugin and the Settings plugin in this manner by requiring that the logged in user be in the ROLE_ADMIN role. Now as Glen Smith would say, that’s a snack!

Update: Burt Beckwith enlightened me to an approach that will get this done without the use of filters that will also direct you to the requested URL after login rather than the main page. Unfortunately I’ve never been able to track this down before. Just add the following to SecurityConfig.groovy:

//...imports excluded for clarity
public class BusinessActivityBinMetaClassHelper {
//...
   public static List<Long> getSrmMetaClassIdListJava(List<BusinessActivityBinMetaClass> businessActivityBinMetaClassList) {
      List<Long> srmMetaClassIdList = new ArrayList<Long?();

      if(businessActivityBinMetaClassList != null) {
         for(BusinessActivityBinMetaClass businessActivityBinMetaClass : businessActivityBinMetaClassList) {
             if(businessActivityBinMetaClass.getSrmMetaClass() != null && businessActivityBinMetaClass.getSrmMetaClass().getSrmMetaClassId() != null) {
               srmMetaClassIdList.add
                  (businessActivityBinMetaClass.getSrmMetaClass().getSrmMetaClassId());
            }
         }
      }

      return srmMetaClassIdList;
   }
//...
}

As I read this code, I thought “This just SCREAMS a need for Groovy’s closure iterators.” So, last night I quickly hacked out fully-equivalent Groovy version of the code:

class GroovyExample {

   static def getSrmMetaClassIdListGroovy(def businessActivityBinMetaClassList) {
      businessActivityBinMetaClassList?.collect { it?.srmMetaClass?.srmMetaClassId }.findAll { it != null } ?: new ArrayList<Long>();
   }
}

Whew! Much nicer. What did we get out of this? Well…

• Groovy’s dynamic typing cleaned up all of the unnecessary type declarations – the only static typing is where we return an empty ArrayList of Longs if the argument to our method is null (a bit of odd behavior, but required to make this code equivalent to the parent Java code.
• We were saved 4 painful null checks by the use of Groovy’s null safe dereferencing operator (?.) and the simplified ternary operator otherwise affectionately known as the “Elvis Operator” (?:).
• Using Groovy’s collect method, we were able to transform the original list into a list containing Long values by passing in a closure that pulls out the property value of interest.
• Because we’re using null safe dereferencing, we are actually inserting nulls into our list if any of the dereferencing fails. Therefore, Groovy’s findAll Collection filtering method comes to the rescue. We simply provide it with a closure that returns true for all of the values we want to keep – in this case, “it != null.”
• Perhaps most importantly, we’ve shorted our code from 11 lines (including whitespace lines for clarity) to ONE LINE that much more clearly expresses the intent of the code.

Great – why don’t we just rewrite the entire application is Groovy? Well, hold on just a minute. At the time we started this application, as much as some of us loved Groovy, we just didn’t have enough Groovy mindshare to go there yet. On top of that, we were already experimenting with several new architectural ideas and technologies, and Groovy would have added yet one more risk to the puzzle. I say all this to acknowledge that sometimes you just can’t move to another language for one reason or another, regardless of how attractive its features may be.

But let’s take a queue from the Pragmatic Programmer and explore the LOTY (Language of the Year) concept one more time. One of the reasons that you’re encouraged to learn new languages is to change the way you program in your main language. You may learn Groovy, Scala, Clojure, Ruby, etc., etc., etc. and never use them in your day job – and yet the experience of coding in a new language with new constructs and idioms will necessarily change the way you THINK about programming in every other language.

So, let’s think about the possibility of coding something that is much more similar to the Groovy version and yet stick with regular Java code. Fortunately, there are several libraries out there that bring much of the flavor and power of Groovy’s closure iterators to Java. I’d like to focus in on one of them, LambdaJ (http://code.google.com/p/lambdaj/).

LambdaJ provides constructs that allow us to “…manipulate collections in a pseudo-functional and statically typed way.” Let’s take a look at this example implementing using LambdaJ:

//...some imports excluded for clarity
import ch.lambdaj.function.convert.Converter
import static ch.lambdaj.Lambda.*
import static org.hamcrest.Matchers.*

public class BusinessActivityBinMetaClassHelper {
//...
   public static List<Long> getSrmMetaClassIdListJava(List<BusinessActivityBinMetaClass> businessActivityBinMetaClassList) {
      return (businessActivityBinMetaClassList != null) ? filter(notNullValue(),convert(businessActivityBinMetaClassList, new IdExtractor())) : new ArrayList<Long>();
   }

   class IdExtractor implements Converter<BusinessActivityBinMetaClass,Long> {
	Long convert(BusinessActivityBinMetaClass from) {
	   if (from.getSrmMetaClass() != null && from.getSrmMetaClass().getSrmMetaClassId() != null) {
	      return from.getSrmMetaClass().getSrmMetaClassId();
	   }
   }
}

Not quite as nice as the Groovy code – we got A LOT out of the null-safe dereference and Elvis operators. However, our overall intent is still a bit clearer. Let’s analyze:

• First we need to implement one of LambdaJ’s Converters. A Converter is nothing more than a generic Interface that defines one method: T convert(F from), where F is the type we’re converting from and T is the type we’re converting to. In this case, we want to convert an object of type BusinessActivityBinMetaClass to an object of type Long. Our implementation determines how this conversion takes place, in this case by extracting the id property from its child.
• Next, after statically importing the methods of ch.lambdaj.Lambda, we call the convert method, passing it our List and our newly implemented Converter. This gives us the equivalent of Groovy’s collect method, with the Converter taking the place of the closure.
• We’re still shoving nulls into our List with this implementation, so we further filter our list using LambdaJ’s “filter” method, passing it the list returned by “filter,” and a Hamcrest matcher that returns only notNullValue()’s.
• Finally, we use our old friend the ternary operator to return the empty ArrayList of Long values if our method argument is null.

If you don’t count the Converter implementation, we’ve gotten ourselves down to 2 lines of code (1 if you don’t mind long lines). In this case I implemented IdExtractor as a named inner class – you could do this with an anonymous inner class and it would look a lot more like a closure, but the added noise of all of the null checking made the undesirable for me. Perhaps if your code has less noise (or guarantees that values aren’t null), that would be a better approach.

Another alternative is to make IdExtractor a top-level class that, if general enough, could be reused throughout the codebase. The benefit of this is that you now have a nice code unit rather than a battery of static methods in a utility class, and unit testing becomes much more clean and elegant.

So, we’ve still made some progress and made our code a bit more Groovy. I encourage you to explore LambdaJ’s feature set and see how it might make your code a bit more concise with clearer intent. And just to stir up a little controversy, look what would have happened in Java 7 had the null safe dereference and Elvis operator’s made the Project Coin cut:

//...some imports excluded for clarity
import ch.lambdaj.function.convert.Converter
import static ch.lambdaj.Lambda.*
import static org.hamcrest.Matchers.*

public class BusinessActivityBinMetaClassHelper {
//...
   public static List<Long> getSrmMetaClassIdListLambdaJ(List<BusinessActivityBinMetaClass> businessActivityBinMetaClassList) {
      return filter(notNullValue(),convert(businessActivityBinMetaClassList,
         new Converter<BusinessActivityBinMetaClass,Long> {
            Long apply(BusinessActivityBinMetaClass from) { return from?.getSrmMetaClass()?.getSrmMetaClassId()}
         })) ?: new ArrayList<Long>();
   }
}

Nice, huh?

• It is only capable of handling payments for one item transactions via “Buy Now” buttons. I want to upload an entire shopping cart full of multiple items.
• It currently won’t handle shipping addresses. The site I’m building allows the user to maintain a list of shipping addresses, and I’d want to send the address information they choose along to PayPal.
• Minor issue: needed to upgrade the plugin to Grails 1.1.

So, I decided this evening to fork the plugin. I want to leverage all of the great work that has been done thus far (especially with the IPN processing part – superb stuff), but I have to add in these two functions and do the version upgrade. Interestingly enough I couldn’t get the tests to run out of the box after the upgrade. No good developer likes to modify code without a stable running test suite, right? So what I ended up doing was creating a new Grails 1.1 plugin project and copying the original artifacts over. Once this was done all of the tests ran perfectly.

So, at this point I’ve added function #1. You can now redirect to the “uploadCart” action. It assumes that you have already constructed a Payment object (now containing PaymentItems) and saved it, and then passed the transactionId along. I did this so that folks with multiple different ways of handling shopping carts could have some degree of flexibility – the onus is on you to map your cart to your Payment object correctly. The original functions implemented by Graeme are backward compatible, assuming only one PaymentItem in the Payment. I’ve run all of the original tests and also did some manual functional testing by running the plugin app against my own PayPal Sandbox account. So far so good. Look for more updates as this evolves. Once I get something I’m totally happy with I’ll see about getting it pushed back into the main plugin repo.

Want to take a closer look? Visit http://github.com/mstine/grails-paypal-plugin/tree/master

After reading the task definition today, I couldn’t resist taking a crack at the problem in Groovy, especially since tackling a Builder DSL is not something I’ve gone after before.

So, here’s how I’ll use my DTOBuilder to produce the output Joel described:

def bldr = new DtoBuilder()

println bldr.build {
	packageName 'edu.bogusu.registration'
	name 'Student'
	field(name:'id', type:'String')
	field(name:'firstName', type:'String')
	field(name:'lastName', type:'String')
	field(name:'hoursEarned', type:'int')
	field(name:'gpa', type:'float')
}

Pretty concise, eh? Check out the implementation of it at GitHub. I’ll be posting all of my code related to this series at this location (and hopefully Joel will join in as well).

One thing you’ll notice is that I’m still operating primarily in OO style. My next task is to refactor this code, still written in Groovy, but using as much functional-style as I can squeeze out of the language. Until next time…

private def evaluateCaptcha(def remoteIp, def challenge, def response) {
    def config = recaptchaService.getRecaptchaConfig()

    def urlString = "http://api-verify.recaptcha.net/verify"
    def queryString = "privatekey=${config.recaptcha.privateKey}&remoteip=${remoteIp}&challenge=${challenge}&response=${URLEncoder.encode(response)}"

    def url = new URL(urlString)
    def connection = url.openConnection()
    connection.setRequestMethod("POST")
    connection.doOutput = true

    def writer = new OutputStreamWriter(connection.outputStream)
    writer.write(queryString)
    writer.flush()
    writer.close()
    connection.connect()

    def recaptchaResponse = connection.content.text
    log.debug(recaptchaResponse)

    recaptchaResponse.startsWith("true")
}

I have to credit Justin Spradlin for the code that ultimately got me here. Consider this a +1.

Basically what prompted this was the need for my wife to be able to sort the various product images that she had on a screen at any given time in any way that she pleased, and it had to be easy to work with. What follows is by no means a complete solution to this problem, but it represents where I am in the development process and may be useful to you, my hapless reader.

Here’s some GSP code which basically lays out a grid of product images, 3 wide by n deep:

<div id="productThumbContainer">
  <g:set var="rowIndex" value="${0}"/>
<g:each in="${products}" var="product" status="index">
  <g:if test="${index % 3 == 0}">
    <div id="productRow${rowIndex}" class="span-20 last product-row">
  </g:if>
  <div id="product_${product.id}" class="span-6 product <g:if test="${(index % 3 == 2) || ((products.size() - index) == 1)}">last</g:if><g:else>append-1</g:else>">
    <img src="${resource(dir: grailsApplication.config.store.productImages.webPath, file: product?.thumbnailImage?.name)}" width="230" class="productImage">
    <h3><g:link controller="product" action="show" id="${product.id}">${product.name}</g:link></h3>
  </div>
  <g:if test="${(index % 3 == 2) || ((products.size() - index) == 1)}">
    </div>
    <g:set var="rowIndex" value="${rowIndex + 1}"/>
  </g:if>
</g:each>
</div>

Now here’s where the magic happens:

document.observe('dom:loaded', function() {
      var productRows = $$('.product-row');

      var options = {
        constraint: false,
        overlap: 'horizontal',
        containment: productRows,
        dropOnEmpty: true,
        tag: 'div',
        onUpdate: updateRows
      };

      productRows.each(function(item) {
        Sortable.create(item, options);
      });

      $('persistOrderingButton').observe('click', function(event) {
          var sortString = '';
          productRows.each(function(row) {
              sortString += '&';
              sortString += Sortable.serialize(row);
          });
          <g:remoteFunction action="sortProducts" params="sortString" update="ajaxMessage" onSuccess="\$('ajaxMessage').show()"/>
      });
});

What we’ve got here is, failure to communicate…oops, wrong synapse there…what we’ve got here is a Prototype selector that grabs everything with the class “.product-row.” It then takes these and creates a Scriptaculous Sortable for each of them, providing the object-literal “options.” Notice the “containment” option which allows you to drag products back and forth between the various rows.

Delving deeper into the magic is the callback function “updateRows.” This guy is my favorite Javascript creation in quite some time:

function updateRows(list) {
      var children = list.childElements();

      if (children.size() < 3) {

        //If I'm the last row, who cares!
        if (list.next() != null) {
          var prevRow = list.previous();

          if (prevRow != null) {
            var lastChild = prevRow.childElements()[prevRow.childElements().size() - 1].remove();
            list.insert({top:lastChild});
            updateRows(prevRow);
          } else {
            var lastRow = list.up().childElements()[list.up().childElements().size() - 1];
            var lastChild = lastRow.childElements()[lastRow.childElements().size() - 1].remove();
            list.insert({top:lastChild});
            updateRows(lastRow);
          }
        }
      } else if (children.size() == 3) {
        //Do nothing...gets me out of the recursion I hope!
      } else {
        var nextRow = list.next();
        var lastChild = children[children.size() - 1].remove();

        if (nextRow != null) {
          nextRow.insert({top:lastChild});
          updateRows(nextRow);
        } else {
          var topRow = list.up().childElements()[0];
          topRow.insert({top:lastChild});
          updateRows(topRow);
        }
      }

      var i = 0;
      Sortable.sequence(list).each(function(item) {
        var productId = 'product_' + item;
        if (i < 2) {
          $(productId).removeClassName('last');
          $(productId).removeClassName('append-1');
          $(productId).addClassName('append-1');
        } else {
          $(productId).removeClassName('last');
          $(productId).removeClassName('append-1');
          $(productId).addClassName('last');
        }
        i++;
      });
}

This function is organized around the fact that the only valid state for a grid of n-rows will be n-1 rows of 3 products, followed by one row of 1 <= numProducts <= 3. In most cases, if you drag a product from one row to another, you are violating that rule by creating a row with 2 products and a row with 4 products. This function solves the problem by recursively shifting the products down until reaching a stable state again.

There's a bit of noise there at the bottom of the function. I'm using Blueprint CSS to do the layout for this application and I need to shift the various Blueprint classes around once everything is settled.

Finally, here's the persistence of the data when we click save:

def sortProducts = {
    TreeMap rowMap = new TreeMap()

    params.each {key, value ->
      def matcher = key =~ /productRow(.*)\[\]/
      if (matcher.matches()) {
        def rowId = matcher[0][1]
        rowMap[rowId] = value
      }
    }

    def productIds = []
    rowMap.values().each { row ->
      row.each {
        productIds << it.toLong()
      }
    }

    shoppingService.saveSortOrder(productIds)

    render("Product sort order saved!")
}

and the logic from shoppingService.saveSortOrder():

def saveSortOrder(def productIds) {
    def productsToSort = Product.findAllByIdInList(productIds)

    def productMap = [:]
    def sortIndexList = []

    productsToSort.each {
      productMap[it.id] = it
      sortIndexList << it.sortIndex
    }

    sortIndexList.sort()
    sortIndexList = sortIndexList.reverse()

    productIds.each {
      productMap[it].sortIndex = sortIndexList.pop()
    }

    productsToSort.each {
      it.save()
    }
}

You might wonder why this is so complex. What I haven’t fully described is the way products are organized into a hierarchy of various categories. When you’re sorting a screen, you’re only sorting a subset of the products that are in that particular category. However, the sort order is maintained across the entire product set in the database. So, this logic basically just shifts around the existing sort indicies, placing them in their new relative order.

Anyway, I don’t know how generally applicable this code is, but I had fun writing it and I hope you can get some use out of it. Cheers!

Since establishing and reporting on these goals, I’ve had several things get in the way of fully realizing all of them. However, I can safely say that in the last two years I have mastered enough Groovy and Grails that they no longer fit in the LOTY category. At this point they’re really not showing my anything that is causing any paradigm shifts for me. They’re comfortable. When I learn a new feature, it just seems to make sense, and nothing surprises me anymore. Languages like these aren’t good LOTY candidates because one of the purposes of learning a LOTY is to challenge and change your ideas about programming. Groovy doesn’t do this for me anymore. It’s time to move on (not to say that I’m dropping Groovy and Grails as a tool – I’m using them more now than ever – they’re just not a learning tool for me anymore).

So, at this point I want to delve into a language that attempts to tackle the concurrent/multicore programming challenge. I’d like to stay on the JVM because I appreciate the benefits that it brings as a platform, so for now Erlang is out. The two leading candidates in the JVM/concurrent/multicore arena seem to be Scala and Clojure. An added benefit of both of these languages is that they support the functional paradigm, something I haven’t really played with since my computer science education days and a very interesting language named Haskell.

Scala is a multiparadigm language, supporting both object-oriented and functional constructs. It is statically typed, yet offers very nice type inference. Clojure, on the other hand, is a functional Lisp derivative with almost no OO constructs that is dynamically typed. Both are designed to enable concurrent programming. Which one do I choose? I open the floor for comments.

On to the meat. I’ve been steadily working on a couple of Grails applications, one being the website for the Memphis JUG, and another being the e-commerce site for my wife’s soon to be launched designer stationery business. Just like your average Grails developer, I’ve been happily coding away at 127.0.0.1 using the good old development Jetty+MySQL stack. Well, in the last week or so it’s come time to actually deploy both of these applications into production. I started out last weekend with the Memphis JUG site. My first approach was to build the WAR file locally and then “scp” it up to the server.

YMMV, but the upload speed on my DSL connection is horrible! After doing this three or four times in one night, waiting 15-20 minutes for the WAR to upload each time (Grails WAR’s are rather thick when carrying all of the dependencies along), I decided to myself, “There must be a better way to do this.”

Fast forward a week and here I sit working on the first “pre-production” release of my wife’s store site. With quite a bit of time on my hands during these “dark and early” hours (a story for a later entry), I decided it was time for the experiment.

Each of these projects is hosted at GitHub, so the process that I mapped out in my mind looked like this:

1. Check out the latest code from GitHub
2. Run “grails war”
3. Stop the Tomcat service (my hosting provider sets up Tomcat to run as a service)
4. Delete the remnants of the previous deployment from Tomcat’s deployment directory
5. Copy the new WAR file to Tomcat’s deployment directory
6. Start the Tomcat service

By the way, I forgot to mention that before doing all of this I moved the production data source definition from being locally defined to being a JNDI lookup within Tomcat. This posed its own challenge, which I’ll blog about a bit later.

Anyway, back to the deployment. I though this would be an excellent opportunity to take Groovy’s Antbuilder out for a spin. Here’s an example of what I put together:

#!/usr/bin/env groovy

def ant = new AntBuilder()

//Update the codebase from GitHub
ant.exec(executable:'git', dir: "${PROJECT_DIR}") {
        arg(value:'pull')
}

//Generate the WAR file using Ant
ant.ant(dir:'"${PROJECT_DIR}"', target: 'war')

//Stop Tomcat
ant.exec(executable:'service') {
        arg(line:'tomcat6 stop')
}

//Delete the old webapp contents from Tomcat's deploy directory
ant.delete(includeemptydirs:'true', verbose:'true') {
        fileset(dir:"${CONTEXT_ROOT_DIR}", includes:'**/*')
}

//Copy the new WAR file to Tomcat's deploy directory
ant.copy(file:"${WAR_FILE}", tofile:"${CONTEXT_ROOT_DIR}/ROOT.war")

//Start Tomcat
ant.exec(executable:'service') {
        arg(line:'tomcat6 start')
}

As you can see, I have a few undefined Groovy constants in there. Let’s just say I didn’t want to expose ALL of the details of my server.

At any rate, it’s pretty simple. One word of warning – if you’re using Ehcache, make sure to add it to your ivy.xml dependencies, or the Ant build won’t bring it in like running “grails war” will. I hope someone finds this simple script useful. Enjoy!


"Linked Text":http://www.site.com


This syntax will result in the following HTML:

<a href="http://www.site.com">Linked Text</a>

Unfortunately, if you have a bang (!) in your “Linked Text,” most of the Textile engines that I used would not recognize it as an HTML link. Plextile does!

The only drawback, however minimal, to using Plextile is that it does not come with a pre-packaged JAR file. You have to take the compiled code and JAR it yourself. Now, for free, I’ll include how I integrated Plextile with Grails. Grails has a very nice codec feature that provides a facility to register encoders and decoders of textual data as methods on any object. Grails searches for classes following the convention XCodec and dynamically registers encodeAsX and decodeX methods on java.lang.Object so that any data can be encoded and decoded. Enter the TextileCodec:

import com.plink.plextile.TextParser

class TextileCodec {

   static encode = {str ->
      new TextParser().parseTextile(str, true)
   }

}

Believe it or not, that’s it! Here’s the GSP template for rendering a JUG meeting:

<div class="post">
  <h2>${event.title}<br/><br/><g:formatDate format="EEEE, MMMM dd, yyyy" date="${event.startTime}"/><br/><g:formatDate format="h:mm" date="${event.startTime}"/>-<g:formatDate format="h:mm a" date="${event.endTime}"/><br/><g:if test="${!event.archived}"><a href="http://jugevents.org/jugevents/event/${event.jugEventsId}">Click HERE to register!</a></g:if></h2>
  <div class="entry">
    <h2 class="title">Speaker/Topic:</h2>
    <p>${event.description.encodeAsTextile()}</p>
    <h2 class="title">Location/Directions:</h2>
    <p>${event.location}</p>
    <p>${event.directions.encodeAsTextile()}</p>
  </div>
</div>

Enjoy!