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!

In the second portion of his talk, Jeremy talked about connecting to Spring. I was really hoping that the “goods” would be delivered here. He started by mentioning DWR, which I think is a really nice framework. It merited 2 slides and no demo (even though there was a slide mentioning a demo). I don’t think Jeremy really cares for it or GWT, as he sort of lumped them together and didn’t mention them again. I do appreciate his point that neither really allows you to harvest any existing controlling infrastructure that we may have built using Spring MVC or another framework.

Jeremy then moved into what he considers the better way to do it, which is the progressive enhancement I mentioned above. He took the existing Spring Booking MVC + Web Flow example application and ajaxified portions of it. He did this using an interesting combination of Apache Tiles, some Javascript “pseudo-AOP” he lifted from the SpringFaces project, and a bit of Dojo. It seemed to work really well, but it wasn’t immediately clear how this type of technology was going to be made available to us as developers. He said something along the lines of “you don’t have to be using JSF to use this Javascript, so we probably need to change the name to something else.” I hope they figure out soon so I can get my hands on it.

He closed by briefly discussing REST’s place in the future of Spring Web. The ideal scenario, according to Jeremy, is that we will be able to request different representations of the same resource. For example, we could request HTML for full page display or partial DOM updates, and JSON for intelligent widgets like the Dojo table.

It looks like a lot of exciting things will happen in 2008. I hope I don’t have to wait too long.

The two sessions that I attended were:

- RubyTooling: State of the Art
- Using Ajax with POJC (Plain Old JavaServer Faces Components)

I attended the first session simply to get a little more detail on all of the hype surrounding Ruby tooling support in NetBeans 6. What I got was even more than I bargained for. The project leaders actually walked us through not only the features that were available, but how they were implemented. I had never really thought about the problems with providing code completion and refactoring with a dynamically-typed language. It was really cool to see the thought process that went into their solutions. I’d love to hear a similar discussion from the JetBrains guys, as the Ruby support in IntelliJ IDEA is quite good as well.

For me the second session was the best of the conference for me up until that point, and arguably it still is after attending Friday’s sessions. Craig McClanahan, of Struts fame, was the main speaker and was joined by his colleagues Matthew Bohm and Jayashri Visvanathan. What made this session so good for me was that they presented a problem – “How can I add Ajax behaviors to my JavaServer™ Faces technology based application, without throwing away my investment in existing component libraries?” – and then provided three different solutions to that problem – low, medium, and high level.

The low level consisted of simply using the HTML event pass-through attributes that are implemented by most standard JSF components (onClick, onBlur, etc.). One could use an existing JavaScript framework such as Dojo to send an XMLHttpRequest and then map that request to a Servlet or JSF handler using a technology such as Shale Remoting. The response could be sent back as JSON data which could then be transformed into the desired UI update.

The medium level consisted of actually extending existing JSF components and adding the desired Ajax behavior. Due to time constraints they didn’t cover this solution in detail, but they did provide a link to a detailed discussion in the Java BluePrints catalog: https://blueprints.dev.java.net/bpcatalog/ee5/ajax/extendingRenderFunctionality.html

The high level solutions addressed the following needs (copied directly from the slides):

● Partial page submit—gather up a particular set of
input element values, and send them to a bit of server
side business logic
● Partial page refresh—the business logic needs to
refresh the content of one or more subtrees of the
client side DOM
● Synchronization—the benefits of synchronizing the
server side state
● Don’t repeat yourself (DRY)—reuse existing
components and renderers for partial page updates

To address these issues, the speakers highlighted two add-on frameworks:

● Ajax4JSF (http://labs.jboss.com/portal/jbossajax4jsf)
● Dynamic Faces (https://jsf-extensions.dev.java.net/)

I was quite impressed with both of these frameworks. One of my colleagues is currently implementing Ajax behavior in a Facelets-based application using Ajax4JSF and he is quite happy with it. Dynamic Faces looked really awesome, especially its tooling support in NetBeans (actually I’m quite impressed with the overall JSF support in NetBeans – I’ll definitely be adding it to my tool belt). The highlight of the presentation was Matt’s video of him building an entire currency trading application in 28 minutes – except it was “fast-played” to finish in 3 1/2 minutes and set to techno music. Matt wowed us with his dancing abilities while we watched true RAD. The crowd went wild!

- Creating Amazing Web Interfaces with Ajax
- jMaki: Web 2.0 App Building Made Easy
- Fast, Beautiful, Easy: Pick Three – Building Web User Interfaces in the Java Programming Language with Google Web Toolkit
- Killer JavaScript Technology Frameworks for Java Platform Developers: An Exploration of Prototype, Script.aculo.us, and Rico

I have to say that I was rather impressed by what I saw.

The first talk was by Ben and Dion, the Ajaxian guys. It was an appropriate way to start, as they gave a quick history overview of Ajax. One nice point they made was that Ajax really isn’t about the acronym – it never was – it’s about building killer websites. Who cares what the actual technology behind it is. They discussed a couple of what they seemed to consider the better frameworks available – Dojo and ExtJS. They then explored some amazing up and coming features, including offline support and 2D client side graphics manipulation.

I was rather impressed with jMaki – in short it is a wrapper around many of the popular JavaScript frameworks available (Dojo, Yahoo UI, Script.aculo.us, Spry, Google), and makes them accessible to Java, PHP, and Ruby. It has excellent tool support in NetBeans and Eclipse. It provides protection from changes in the API’s of all of these projects – you can mix and match frameworks and only be concerned about one API – jMaki’s. It does the work of linking all of the widgets together and communicating amongst them and with the server side.

The GWT talk was easily my favorite of the day. I’m extremely impressed with what these guys have done. I hadn’t had much opportunity to look at GWT until now, and I really wish I had. I was initially skeptical about writing an entire application in Java and letting it generate HTML and JavaScript. I guess these guys knew that, because they’re development philosophy addresses my concerns quite nicely:

To radically improve the web experience for
users by enabling developers to use existing
Java tools to build no-compromise AJAX for
any modern browser

From what I can see, they deliver on their mission. They’ve optimized their code for speed and for browser specificity (e.g. from what I understand, if your client is using Firefox, you get Firefox optimized JavaScript, same for IE, etc.). You can use all of your favorite IDE features to build the code, including the debugger. I really want to try to make use of this toolkit in the near future.

The final talk was less informative for me, but only because I had experience with most of the technologies already. The killer part of this was how the speaker extended existing JSF components and added Script.aculo.us effects. It really made his version of Yahoo maps shine.

Ajax isn’t going anywhere but up. I just left yet another Ajax/JSF session, which for me was the best session of the conference so far. In a later entry I’ll tell you why.