Grails

Multiple Data Sets on Line Charts with Google Chart Plugin for Grails

Posted on by Matt Woodward

I’m working on a Grails project and we’re using the very slick Google Chart Plugin to handle the charting aspects of the project. If you aren’t familiar with the Google Chart API be sure and check it out; even if you aren’t using Grails it’s a really simple way to add charting to any application. You just call a URL on Google and in return you get a very nice looking chart, and it supports just about any type of chart you can think of. Cool stuff.

One of my tasks today was to get a line chart up and running, and I was having a bit of trouble getting multiple datasets working on a line chart when using two separate Groovy lists. The solution turned out to be simple but since it took a bit of head banging to get there I figured I’d share in case others run into this.

The data I have is simple integers in two Groovy lists (let’s call them dataSetA and dataSetB), and in my controller I’m putting the lists in the model for the view so they’re already available. Here’s the syntax for a simple line chart using the Google Chart Plugin with one data set:

<g:lineChart
    size="[400,300]"
    colors="['00ff00','ff0000']"
    type='lc'
    legend="['Data Set A', 'Data Set B']"
    fill="bg,s,efefef"
    dataType='simple'
    axes="x,y"
    data="${dataSetA}" />

This worked fine. To add a second data set, you simply separate the two data sets with a comma, so you’d think this would work (or at least I did):

<g:lineChart
    size="[400,300]"
    colors="['00ff00','ff0000']"
    type='lc'
    legend="['Data Set A', 'Data Set B']"
    fill="bg,s,efefef"
    dataType='simple'
    axes="x,y"
    data="${dataSetA},${dataSetB}" />

For some reason the lineChart tag doesn’t like that syntax. I’ll save you the various things I tried to get the data into the right format so I could pass the lineChart tag a single attribute and just give you the solution. Basically you just create a new list using the two existing lists as its elements:

<% def combinedDataSets = [ dataSetA, dataSetB ] %>

<g:lineChart
    size="[400,300]"
    colors="['00ff00','ff0000']"
    type='lc'
    legend="['Data Set A', 'Data Set B']"
    fill="bg,s,efefef"
    dataType='simple'
    axes="x,y"
    data="${combinedDataSets}" />

As I said, very simple fix but it took me a while to get there. Be nice, I’m still kind of new to Grails. šŸ˜‰

Hope that helps someone else who may run into this.

Replace Amazon S3 with MongoDB GridFS and Grails

Posted on by Matt Woodward

My recent forayĀ into MongoDB got me thinking about using it to serve files. You can do just that with MongoDB’sĀ GridFSĀ specification. When a file is stored in GridFS, it is represented by a metadata object and one or many chunks which store a subset of the data. Chunking the files helps with searching but could help replication and sharding presumably. Files in a GridFS store are just like any object in the database. You filter by any of the metadata properties and get chunks on demand or out of order.

Very slick use of MongoDB with Grails.

Grails 1.2 Released

Posted on by Matt Woodward

Grails 1.2 final was released today, and there's tons of great new features as well as numerous under-the-hood improvements that make it a very compelling release.

Since I'm relatively new to Grails I'm still wrapping my head around some of the new stuff, but here are some of the more interesting changes in 1.2 from my perspective:

  • Performance Improvements
    Faster is always better of course, so the first thing that caught my eye was the performance improvements in GSP/SiteMesh and the tag library return types (default is now StreamCharBuffer, but tags can return object values too).
  • Environments in Bootstrapper
    Not that this was a showstopper in previous versions of grails, but having to use a kludge or do a quick check of the state of your database to see whether or not you should crank out test data seemed a bit wrong since environment awareness is available elsewhere in Grails apps. Now that it's in the bootstrapper too we can do things the "right way."
  • Per-Method Transactions in Services
    I haven't run into issues with this yet but I could see them coming, so it's nice that you can now declare at the method level whether or not something should be transactional.
  • Named Query Support
    I'm still debating whether or not I think this one is a good idea, but it's certainly interesting. Named query support allows you to define named queries right in your domain classes, and these named queries can then be executed in the same fashion as dynamic finders. The really intriguing thing is that you can run dynamic finders on your named queries, which is tremendously powerful. On the one hand I'm thinking, "Queries in my domain class? That seems wrong." But on the other hand, when they're looked at as "customized dynamic finders," I suppose it's really no more intrusive than the dynamic finders themselves. And frankly given the power you can get out of this feature it's probably worth the small purity of architecture trade-off.
  • Support for SQL Restrictions in Criteria Builder
    Much as I love GORM, sometimes it's simpler to throw some ad-hoc SQL at a problem. This is now supported in the criteria builder which should make lots of the "grab stuff then grab stuff from that stuff" type code disappear (if that made any sense!).
  • GSPs are Pre-Compiled in WAR Deployments
    Small new feature, huge impact in my opinion. On Tomcat instances where we're running a few other apps (especially on 32-bit Windows servers … don't get me started), we noticed that Grails apps wouldn't start up due to out of memory errors that I strongly suspect were related to this issue. Pre-compiling GSPs reduces the amount of permgen memory space used on deployment.
  • Tomcat is Now the Default Container
    I didn't have a problem with Jetty personally but since we use Tomcat in production it's nice it will be Tomcat in development as well. Note that you can still use Jetty if you like since all the container support is done through plugins. The Tomcat Plugin has a ton of cool additional features like JNDI support in Config.groovy for the embedded Tomcat instance, as well as remote deploy/undeploy scripts. Yes, you can do "grails tomcat deploy" to deploy your app to a remote server. Sweet.
  • Named URL Mappings
    Very handy feature that lets you create URL mappings that may be linked to by name in the link tag/function. For example if you define a URL mapping with the name "fooBar" with attributes of foo and bar, your link tag in a GSP would be <link:fooBar foo="foo" bar="bar">Link to FooBar</link>
  • Improved JSON Builder
    Some nice changes (and an under-the-hood rewrite apparently) here, but note this is a breaking change from previous versions. You can turn on compatibility if you don't want to re-write your code to take advantage of the new simpler syntax.
  • Better Date Parsing
    One of the very few things I've run into in Grails so far that I thought to myself, "this could be simpler," is the way the date picker passes its params to controllers. Now it works like it should have all along.

Much more in this release so be sure and check out the release notes for all the details.

Kudos to everyone involved with this release! Can't wait to upgrade the current app I'm working on and give this all a whirl.

Session Notes – Grails Without a Browser

Posted on by Matt Woodward

Presenter: Jeff Brown, SpringSource

  • grails typically thought of as a web framework (which it is), but there are significant applications built with grails that have no browser front-end at all
  • interesting work done at LinkedIn in this regard
    • talked about it in public at JavaOne last year
    • primary revenue generating app is a grails app (partner interaction, etc.)
      • this app has no browser front-end to it
      • built a business/service layer all in grails
      • have other applications that sit in front of this that aren’t grails
  • lots of stuff in grails doesn’t have anything to do with building web apps specifically
    • GORM
    • service layer
    • these make good sense in any application
  • can think of grails as a platform–similar to eclipse platform
    • eclipse IDE is what you think of, but the IDE is really just one app on top of the eclipse platform
    • e.g. substantial parts of grails are being used in griffon for building desktop apps
  • grails 0.4 was the first release that had the plugin system in it
    • interview soon after this release–jeff was asked what was coming up in the following year
    • hope was that they’d see a lot of development in the plugin space
    • turned out that there’s a far more active and productive plugin community than they had hoped
    • shows the power of the plugin architecture in grails as well as grails as a platform in general
  • some plugins have nothing to do with an html ui
    • remoting plugins
      • exposes services to remote calls
      • can have the grails side interacting with GORM as per usual, but make these services available to RMI, SOAP, etc.
    • good REST support built right into the framework

Code Demo

  • simple app with Car domain class, CarService
  • services
    • transactional by default
    • instance of service class is automatically added to the spring application context
  • installing xfire SOAP plugin
    • inside a service can declare a property using “expose”, e.g. static expose = [‘xfire’] in the service
      • this will inspect services that have an expose property declared and make them available via xfire
    • also plugins for exposing as rmi, jms, etc.
  • after fire the app up can browse to http://localhost:8080/context/services to see a list of service WSDLs
    • xfire generated the wsdl automatically
    • can test with something like SOAP UI–UI tool to allow you to exercise web services
  • as you define other operations within the service, the WSDL gets regenerated as needed to expose the new methods
    • with xfire you do need to bounce the app for it to pick up the changes
  • creating a groovy script as a command-line client to the exposed service
    • create a groovyx.net.ws.WSClient, give it the URL to the WSDL, and can then call methods on the web service
    • WSClient is an external project (not core to groovy) so you do need to add it to your classpath
  • note that you don’t have access to the Car class when you get back data from the web service
    • you aren’t getting back serialized Car objects, it’s returning WSClient type of ArrayOfWhatever
      • basically you get back a list of arrays–each array contains the property of the Car object
        • really JAXB elements that contain an xml representation of the car
  • note that by default all of your services are singletons (stateless)
    • if you do happen to have a service that DOES have state, need to worry about thread safety
      • can specify that the bean is scoped in any one of the valid spring scopes
  • controllers are not singletons since they have state–new controllers are created for every request
  • xfire may or may not support (need to check) not exposing specific methods within a service using something like webparam annotations
  • installing jmx plugin
    • can add another entry to the expose property, e.g. static expose = [‘xfire’, ‘jmx’]
      • still exposed as SOAP, but also available to jmx
  • creating simple math service
  • can create a griffon client to access the grails service
  • demoing creation of griffon app (results in a swing app)
    • showing two text input fields in swing app, click button to make call to grails service to add the two numbers together
    • actually clicking on the button calls a griffon controller, and the griffon controller makes the web service call to the grails service
      • creating an instance of groovy’s WSClient in the griffon controller and calling the same way as from the command line client
  • now creating a RESTful interface to the math service
    • adding a MathController to the grails app with a “product” action to multiply two numbers
    • return from the controller is xml
    • showing calling this in the browser but of course this could be called from anything that can accept xml as the return format
  • now adding another component to the griffon application to do multiplication by calling the REST URL in the grails app
    • plugin for griffon to enable REST support
    • wind up with two buttons in the griffon app, one that makes a soap call, the other making a rest call
  • can use UrlMappings in a grails app to make things more RESTful
  • in controller you can specify the allowed HTTP request types that can be made to the controller by action, e.g. static allowedMethods = [delete:’POST’] would throw a 405 if any request type other than POST is made to the delete action
    • should never do anything destructive in response to a get request
    • if you write controllers from scratch the allowedMethods property is NOT there, and in most cases you’ll want to add it
  • in RESTful services, the request will come to the controller since controllers in grails apps are what respond to requests
    • can put logic in services to get it out of your controller, but the REST response since it’s based on HTTP request/response needs to be handled in the controller
    • controllers don’t have to render a *view* specifically, they just have to provide a response
      • response can be html, xml, json, etc.
  • when you think about grails, building web apps is a huge part of what it’s used for, but grails also handles “no browser” apps or multiple UI clients quite well
  • in the end your application is just responding to requests

Q&A

  • anyone working on a plugin so you can write an app that can render either a grails or griffon app?
    • nothing really going on in this specific area, but moving towards compatibility with grails and griffon plugins
    • in many cases you can do a search/replace on a grails plugin to replace “grails” with “griffon” and it’ll work in griffon
  • has linkedin experienced any scalability issues?
    • linkedin app get hits really hard and is holding up very well
    • being on the jvm means you have great existing solutions for deployment, scalability, monitoring, etc.
      • can do things in other frameworks (e.g. rails, django) perhaps as quickly as with grails, but that’s only one piece of the puzzle
  • what happens when an app and a plugin rely on different versions of the same jars?
    • no good solution for this at this point
    • after grails 1.2 is released, significant effort will be put into the plugin system–need to figure out what role OSGi will play in the future of grails
      • will grails apps and/or plugins turn into OSGi bundles? probably ponder this early next year
  • is GORM usable outside of Grails?
    • yes, and isn’t difficult to do now
    • wiring between gorm and the rest of grails is pretty decoupled at this point
    • can use GORM in griffon, for example–drop the GORM jar in and annotate classes, and everything works
      • all the gorm dependencies are in 1 JAR now
    • when using GORM outside of grails you do need to create your own boostrapper or use annotations so GORM knows about your domain model
  • error handling with soap?
    • inside controller action if you get bad data you can render the soap response with the error
    • grails doesn’t complicate or simplify any error handling with soap
    • anything you can do to specify timeouts, etc.?
      • rest client for griffon no, wsclient probably does
    • shouldn’t assume when something goes wrong in groovy/grails that you always get an exception
      • in many cases grails fails silently, e.g. if you call save() and it fails, it doesn’t throw an exception it just returns null
      • can now specify that save() throws an error if save fails
  • what about security with xfire and securing services?
    • can secure access to the webapp at the http level
    • don’t know if xfire plugin has specific user/role based access
    • controllers in REST would hook into everything that grails already does–just an http request to the webapp

Session Notes – Not Your Father’s Custom Tags

Posted on by Matt Woodward

Presenter: Dave Klein

Custom Tags are Valuable

  • build reusable components
  • keep code out of pages
  • make pages more readable
    • even putting presentation/html code into custom tags can make the page more readable
  • encapsulate domain knowledge
    • easy for page designers to use without knowing much about the domain model, etc.

JSP Custom Tags are Painful

  • create handler class for each tag
  • implement one of several interfaces
  • implement interface’s methods
  • <pure_evil>define a TLD</pure_evil>
  • add a page directive for each TLD
  • great once they exist, but because they’re a pain to create people avoid them and don’t get the benefit
  • JSP custom tag for hello wolrd is 2+ pages of code, equivalent GSP tag is about 6 lines

The Power of JSP Without the Pain

  • convention over configuration
  • no tld, no xml
  • no interfaces to implement
  • a TagLibrary is a single groovy class
    • can contain multiple tags within this class
  • each tag is a closure
  • don’t need to declare within the page
    • if it’s in the project, it’s available on every page

GSP: A Quick-Start Guide

What you can do in a GSP tag

  • accept and use attributes
  • accept and conditionally use a body
  • access your domain model including all the GORM methods
  • call service classes
  • call other tags
    • other tags are called as methods from within a tag
  • access the session, request, and response

Implicit Objects in a GSP Tag

  • session (GrailsHttpSession)
  • request (HttpRequest)
  • response (GrailsContentBufferngResponse)
  • out (GSPResponseWriter)

Example Tag — Output Groovy Group List

  • def groupLinks = {
    def groups = GroovyGroup.list()
    out << “<br/><ul>”
    groups.each { group ->
    out << “<li><a href='”
    out << createLink(action:’show’, id:group.id)
    out << “‘>${group}”
    out << “</a></li>”
    }
    out << “</ul>
    }
  • call tag as <g:groupLinks />

Example Tag With a Body

  • def ifLoggedIn = { attrs, body ->
    def user = session.use
    if (user)
    out << body()
    }
  • <g:ifLoggedIn>
    info for logged in users goes here
    </g:ifLoggedIn>
  • note that in the tag code, the first parameter will be treated as a map of attrs so even if you’re not using attrs, but you’re using the body, still need to have a dummy parameter for attrs in order for things to work correctly

Using Custom Tags Instead of <g:if>

  • def buttonBar = {
    def user = session.user
    out << “<div class=’buttons’>”
    if (user) {
    // output buttons for logged in users here
    if (user.isAdmin()) {
    // output admin buttons here
    }
    } else {
    out << “<input type=’button’ value=’Login’ />”
    }
    out << “</div>”
    }
  • call tag as <g:buttonBar />

Testing Tags

  • very easy
  • tags when called as methods return a string
  • TagLibUnitTestCase makes it even easier
    • includes mocks for
      • session
      • request
      • response
  • includes other mocks from GrailsUnitTestCase

A Sample Test Class

  • import grails.test.*
    class DemoTagLibTests extends TagLibUnitTestCase {

    public void setUp() {
    super.setUp()
    tagLib.metaClass.createLink = { params ->
    “/groovyGroups/show/${params.id}”
    } // Had to add this because otherwise createLink wouldn’t be available in the test
    // This would also be true of custom tags that aren’t in the same tag library
    }

    void testButtonBarWithAdmin() {
    mockSession.user = [isAdmin:{-> true}] // map is serving as mock object
    def output = tagLib.buttonBar() // tag itself is a closure, so can call as a method here
    assert output.toString().contains(‘Create Stuff’)
    }

    void testIfLoggedIn() {
    mockSession.user = “Anything can go here” // doesn’t matter what goes here since we’re just checking session.user
    def output = tagLib.ifLoggedIn([:]) {
    ‘User is logged in’
    }
    assertEquals output.toString(), ‘User is logged in’
    }

    void testGroupLinks() {
    mockDomain(GroovyGroup, // new GroovyGroup objects here …)
    def output = tagLib.groupLinks()
    assert output = tagLib.groupLinks()
    assert output.toString().contains(‘<a href=’)
    assert output.toString().contains(‘Group2’)
    }
    }

  • remember that unit tests run much faster but don’t have everything available, so if you find yourself mocking a ton of stuff in unit tests, that’s a good indication you need integration tests

Namespaces

  • if you don’t declare a namespace, uses g
  • put static namespace = ‘demo’ at the top of your taglib class to declare a namespace
  • use the namespace as a prefix when calling the tag as a method, e.g. namespace.tag()

Distributing TagLibs With Plugins

  • create a plugin project
  • create or copy a TagLib to the /taglib directory
  • package your plugin
  • Install your plugin in another application
  • your custom tags are now available in the application

Demo

  • showing demo of simple custom tag to replace a lot of the redundant stuff in the grails scaffolding
  • one limitation of gsp tags is you can’t have nested tags
    • you can fake this out a bit by leveraging the request scope
  • great use of gsp tags is to bundle up html, css, and javascript that gets output to the page
  • FieldData plugin available that does a lot of these sorts of things
  • check out the custom tags available in the grails core for good examples of how to do things

It’s Alive! CFML Plugin for Grails

Posted on by Matt Woodward

Nothing to distribute quite yet, but I’m psyched that I just successfully hit an index.cfm in my nascent CFML plugin for Grails. What this means is that (when it’s done anyway) you’ll be able to run CFML from within a Grails application.

Why is this cool? Partially just because it’s fun to mess around with, but there are several practical reasons as well. Here’s a few off the top of my head:

  • Leverage the power of Grails for building the model and controller layer of an application while using CFML for the view
  • Integrate existing CFML functionality or entire CFML applications within the context of a Grails application
  • Write hybrid Grails and CFML applications, mixing and matching CFML and Groovy/Grails code in various sections of the application
  • Use Grails URL mappings to hit CFML or Groovy code based on URL patterns

Creating the plugin was actually relatively simple. The Grails plugin architecture is amazingly powerful and easy to use, and after Graeme Rocher’s two sessions on plugin development today at SpringOne2GX I at least had an idea of how this would be accomplished. I created a new Grails plugin project, dropped the Open BlueDragon JAR files into the Grails plugin’s lib directory, defined the servlets, servlet mappings, and a few other things in the Grails plugin config file, and a basic index.cfm file was processed fine.

I’m still thinking through all the possibilities and potential problems I might run into with this but at least it’s limping along. Exciting stuff, and shows the extreme power of the Grails plugin architecture.

Session Notes – Grails Plugin System Part 2

Posted on by Matt Woodward

Presenter: Graeme Rocher

Technical Plugins

  • typically a bit more complicated to implement
  • can mix and match technical and functional plugins
  • provide programming apis

Key Concepts

  • plugin lifecycle
  • GrailsApplication object
    • encapsulates the conventions in a project
  • Spring BeanBuilder
    • runtime spring configuration–need to understand the spring dsl
  • Metaprogramming

Plugin Lifecycle Hooks

  • enclosures that allow you to manipulate the grails runtime
  • def doWithWebDescriptor = { xml -> }
    • useful for creating plugin that manipulates web.xml
  • def doWithSpring = {}
    • can use full power of spring within a grails plugin
    • written in groovy so have full access to groovy in configuring spring
  • def doWithDynamicMethods = { applicationContext -> }
    • metaprogramming
    • e.g. could add a method that interacts with hibernate
    • since you have access to the applicationContext you have access to more or less everything
  • def doWithApplicationContext = { applicationContext -> }
    • post-processing

doWithWebDescriptor

  • programmatic modification of generated web.xml
  • useful for integrating third-party servlets/filters
  • groovy markupbuilder style dsl
    • easy to append to existing nodes in xml
  • automates a lot of configuration you’d otherwise have to do by hand
  • doesn’t happen during war deployment

doWithSpring

  • programmatically modify Spring ApplicationContext
  • groovy dsl that generates spring xml

doWithDynamicMethods

  • exercise your groovy metaprogramming skills
  • add new methods and properties to existing types
  • “delegate” is equivalent to “it” in metaprogramming
  • in java terms a lot of what you have to do is DI, etc. and your code becomes rather cluttered
    • e.g. in GORM there’s no reference to the fact that you’re using Hibernate in your domain classes
    • specific references are abstracted away

Additional Hooks

  • onChange
    • can re-add a method to a class when it changes
    • e.g. specify def observe = [‘plugins’] to watch for changes
  • onConfigChange

Plugin Life-Cycle Illustrated

  • grails loads first
  • loadPlugins() called next — pluginmanager created
  • following this, the plugin lifecycle points are called
  • all plugins, core and otherwise, are loaded at the same time
    • can specify with your own plugins if they should load explicitly before or after core plugins

Programming by Convention

  • every grails project has a set of conventions
  • configuration can be automated through conventions
  • grails supplies an API to inspect conventions via some key interfaces
    • GrailsApplication
    • GrailsClass

The GrailsApplication Interface

  • used for programming by convention
  • not an interface in the fixed Java term; dynamic object
  • inspect GrailsClass instances
  • extensible to new artefact types
  • available as a variable called application in plugins
  • interesting methods
    • Class[] getAllClasses() // gets all loaded classes
    • GrailsClass get*Class(String name) // gets a class by name
    • boolean is*Class(Class c) // checks if a class is of a given type
    • GrailsClass[] get*Classes() // all grailsclass instances of type
    • void add*Class(Class c)
    • all the * stuff in these examples are where you substitute the grails class type, e.g. getControllerClass(“fully.qualified.class.Name”)
  • can add new artefact handlers to add completely new artefact types to grails
    • can tell grails what the conventions are, e.g. “ends with X” or “lives in this directory”

Artefact Types

  • built in types
    • DomainClass
    • Controller
    • TagLib
    • Service
  • extensible to new by implementing ArtefactHandler

The GrailsClass Interface

  • allows you to further analyze conventions for each class
  • contains methods to get various forms of the class name
    • getShortName(): UserController (no package)
    • getPropertyName(): userController (bean name)
    • getNaturalName(): User Controller
    • others …
      • getLogicalPropertyName(), getPackageName(), etc.

Demo: Building a Technical Plugin

  • building an API to twitter
  • using twitter4j — twitter api for java
    • drop jar in lib directory of project
  • create a new public twitter bean in the doWithSpring plugin point
    • default constructor assumes public timeline
  • in doWithDynamicMethods are going to add ability for spring security users to submit to twitter
    • adding dynamic tweet() method to string class
    • String.metaclass.tweet = { ->
      def auth = SecurityContextHolder.context?.authentication
      if (auth instanceOf UsernamePasswordAuthenticationToken) {
      def twitter = new Twitter(auth.principal, auth.credentials)
      twitter.updateStatus(delegate)
      } else {
      throw new TwitterException(“user not logged in”)
      }
      }

Convention-Based Programming

  • have classes in the system, want to mark these as a “tweeter”
  • want to be able to call twitter methods to a user who’s marked as a tweeter
  • implement this in doWithDynamicMethods
  • inside each hook there is an implicit application keyword that represents the application context
    • application.domainClasses.each { GrailsDomainClass dc ->
      def metaClass = dc.metaClass
      metaClass.tweet = { String message ->
      def twitter = new Twitter(delegate.username, delegate.password)
      twitter.updateStatus(message)
      }

      metaClass.getLatestTweets = { ->
      def twitter = new Twitter(delegate.username, delegate.password)
      twitter.getPublicTimeline().text // property doesn’t exist but gpath automatically grabs text property of each object
      }
      }

Summary

  • more advanced knowledge of the grails plugin system opens up a world of possibilities
  • combine technical and functional plugins to enable new levels of productivity
  • harness the power of groovy metaprogramming!
  • helps avoid reinvention and duplication across applications

Q&A

  • inside any plugin you can do grails create-script and specify a gant script
    • used to extend the grails command line interface
  • plugins can provide different scaffolding templates to override the default ones and create your own uis
  • “plugins are the most important thing about grails”
  • any thoughts about how to eliminate bad/abandoned plugins from the central repository?
    • hudson build of all tests on all plugins done by a user
    • thoughts of integrating this into grails.org to give plugins a health status
  • plans to move plugins into git instead of SVN?
    • in grails 1.2 you can export plugin as a zip only so you can manage your source in git but still deploy to svn
    • complete move to git might be considered further down the line
  • SpringSource officially supports specific plugins

Session Notes – Grails Plugin System Part 1

Posted on by Matt Woodward

Presenter: Graeme Rocher

Agenda

  • plugin quick start

  • technical vs. functional plugins

  • plugins for modularity

  • distribution and dependency management

  • plugin demo

Key Facts

  • grails itself is made up of a collection of plugins

    • hibernate, webflow, gsp, etc.

    • grails core is essentially a set of plugins (about a dozen)

  • there are 300+ plugins available now

    • what a plugin can do is wide and varied

  • plugins are easy to create

    • don’t need to spend a ton of time learning the internals of the framework to create a plugin

  • plugins are easy to distribute

  • everyone is a plugin developer

  • well over 25 million lines of user contributed code in the plugin repository

    • searchable

      • automatically makes any domain class searchable

    • taggable

      • adds apis to tag domain classes

    • rateable

      • ratings for domain classes

    • quartz

      • for scheduling tasks

      • interesting because it adds a new concept to grails — “jobs”

      • adds create-job command to command line, has a jobs directory, etc.

    • gwt

    • weceem cms

      • example of a functional plugin as opposed to just providing new apis

      • this plugin contains views, controllers, domains, etc. as part of the plugin

    • feeds (rss and atom feeds)

    • iwebkit (iphone)

Common Use Case

  • you have a tag library

  • you have two applications

  • you want to share functionality

  • create a plugin!

  • grails create-plugin pluginName creates the plugin skeleton

  • grails 1.2 creates intellij project files

Plugin Structure

  • more or less identical to a grails application structure

  • can run the plugins as standalone apps

    • developing a plugin is the same as developing an application

  • only real difference is there’s a plugin descriptor in the root of each plugin

    • contains info about plugin version, grails versions supported

    • can also exclude specific resources when the plugin is installed

    • also numerous plugin hooks that can be accessed (doWithWebDescriptor, doWithSpring, etc.)

  • using packages is important–should always uses packages in your applications

Plugin Quick Start — 5 steps

  • grails create-plugin myPlugin

  • cd myPlugin

  • grails create-tag-lib myTagLib

  • grails package-plugin

  • grails install-plugin

Plugin Extension Points

  • normal grails development

    • tag libraries, controllers, etc.

    • the build

    • theses are very trivial to do

  • requires additional knowledge

    • spring configuration

    • new apis

      • addition of additional properties/methods to domain classes and domain controllers

    • new concepts

Plugin Types

  • relate to the “split” above

  • functional plugins

    • taglibs, controllers, extend the build, etc.

  • technical plugins

    • see above–spring config, metaprogramming, etc.

Examples

  • functional plugins

    • weceem cms

    • nimble

      • provides user management, integration with facebook, etc.

  • technical plugins

    • gwt

    • functional test

  • both functional and technical

    • spring security

    • searchable

      • adds search to domain classes, but also provides a complete search UI to your application

Functional Plugins

  • easier to understand

  • just like building a normal grails application

  • silos of functionality

    • forums, blog, search, etc.

  • used to create modular applications

Demo: Building a Functional Plugin

  • example: twitter clone

    • two different teams–web UI team, mobile team

    • underlying functionality is the same

  • good candidate for a plugin–need to share the domain model between the two apps

  • can install plugins in other plugins

    • e.g. can install both the iwebkit and the twitter domain model plugin into the iphone version of the app

    • can specify plugins and versions in dependsOn block in the plugin descriptor

    • when you package up your plugin it will bundle up the plugins on which your plugin depends and include them

  • can use BootStrap.groovy within plugins

  • can configure local plugin repositories and can specify order in which plugin repositories are searched

Certain Things that Plugins Cannot Package by Default

  • BootStrap.groovy, UrlMappings.groovy, DataSource.groovy

  • can create something like FooUrlMappings.groovy and that will get packaged

Some Tips

  • inline plugins

    • if you’re modularizing your entire application, becomes impractical to repackage and reinstall every plugin as they change during development

  • url mappings

  • jar dependencies

  • testing

  • plugin distribution

Inline Plugins

  • use plugins without installing them

  • prevents package/install cycle

  • great for modular application development

  • go to grails-app/conf/BuildConfig.groovy and set grails.plugin.location.”pluginName”=”../path/to/plugin”

  • BuildConfig.groovy

    • not generated automatically in 1.1.1

    • lets you configure various aspects of the build, locations of generated files, etc.

URL Mappings

  • normal UrlMappings.groovy file is excluded from the package plugin process

  • if you want to define url mappings as part of your plugin, create a file called something like MyPluginUrlMappings.groovy and that will be included

Plugin Dependencies

  • grails supports transitive installs and plugin dependencies using dependsOn

  • can use ranges of versions for dependencies, e.g. hibernate:”1.1 > *”

  • to implement a “soft” dependency use loadAfter

    • def loadAfter = [“hibernate”]

    • can also specify loadBefore

Plugin JAR Dependencies

  • you can put jar files in the lib directory of the project just like applications

  • even better, in grails 1.2 you can define dependencies in grails-app/conf/BuildConfig.groovy

  • grails.project.dependency.resolution = {
    inherits “global” // inherit grails’ default dependencies
    dependencies {
    runtime “org.apache.ant:ant:1.7.1”
    }
    }

  • different scopes can be involved–build, runtime, test, provided (needed during grails run-app but not during WAR deployment)

  • this means the jar files are NOT included in the plugin packaging

    • allows application into which the application is installed to resolve the dependencies

  • in a traditional java project, the jar dependency list is flat

  • in grails, you have dependencies of the app, of the framework, and of any plugins involved

Testing

  • done just like a normal application

  • sometimes it’s useful to have classes used only for testing and not distributed with the plugin

  • use pluginExcludes in the plugin descriptor to achieve this

  • class MyPlugin {
    def pluginExcludes = [
    “ant/path/here“
    ]
    }

Plugin Distribution

  • central repository

    • grails release-plugin

  • custom repository

    • can configure custom repos in BuildConfig.groovy

    • can also set this in settings.groovy in your user home directory

  • Grails separates notion of repos used for discovery vs. distribution (e.g. http for discovery, https for distribution)

  • can specify the repository into which to release the plugin when you run grails release-plugin

  • custom repos use svn for distribution

    • can use a basic file server for discovery

  • plugins don’t necessarily have to be open source to be in the central repository

    • need to specify the license

    • would distribute jars instead of source

Summary

  • developing grails plugins is very simple

  • functional plugins are an easy way to modularize your application

  • in part 2 we’ll be looking at how to develop technical plugins

Q&A

  • as part of modularization is there any integration with osgi?

    • not yet, but looking into it–probably next year there will be something more concrete

  • are there particular plugins that you would highlight that follow best practices or as good models to follow?

    • depends on what you want to do

    • for a functional plugin check out weceem cms–complete end-to-end with views, js, etc.

    • for a technical plugin check out Build Test Data (creates mock data for you)

    • quartz plugin is a good example of a plugin that adds a new concept to grails, new command line arguments, etc.

      • exercises the artefact api

    • SpringWS plugin adds notion of an endpoint to Grails

    • Ratable, Commentable, Featurable, and Taggable are great examples of modifying domain classes on app load

Session Notes – Spring WebFlow in Grails

Posted on by Matt Woodward

Presenter: Joseph Nusairat, Integrallis About This Talk

  • discuss web flows
  • what are spring web flows
  • show some basics of webflow
  • live demo
  • Grails web flows didn’t really mature until Grails 1.1.1

What is Web Flow

  • allows for controlling the flow of items via steps, substeps, other flows
  • use when you want to control the sequence in which events occur in a series of events
    • e.g. buying a plane ticket on travelocity–goes through a specific series of steps
    • can’t go to point D without going through A, B, and C first
    • also support branches
  • control is not on the page but in a DSL
  • can keep components open for a longer period of time
  • where do you store the information for something like an uncompleted plane ticket order?
    • can store in the database, but would require cleanup for things that never make it to checkout
    • general way people have done this is via session data
      • check out spring memory management session recording on infoq
      • don’t want to use up a lot of your server RAM with sessions that are unused
  • at the end of the flow, data is persisted to a database or somewhere more permanent
  • when you remove the flow aspect of things from the pages themselves, it makes things more flexible and configurable
  • SEAM allows for different timeouts for conversations and sessions themselves

WebFlows in Spring

  • was new in Spring 2.0
  • great integration with JSF for rich UI
  • allows control over the scoping of objects for a limited period of time
  • cannot have multiple conversations
  • uses xml
    • xml is great for transferring objects, but not great for configuration
    • configurations aren’t generally that black and white

Creating a WebFlow

  • WebFlow in 1.2 M3 doesn’t work at the moment
  • GRAILS-5185
  • demo will be in 1.1.1
  • in 1.2 WebFlow is a plugin (grails install-plugin webflow)
    • in 1.1.1 it’s built in, but in 1.2 you have to install the plugin to use it
  • flows live in the controller
    • look just like an action, except ends with “Flow”
      • e.g. def bookingCartFlow = {}

Defining a View

  • views represent the individual pages
  • demo of hotel booking flow
    • “do you want to pay via paypal?” — decision point with branch
  • def bookingCartFlow = {
    start() {}
    }
    • whatever is defined first is the starting point–doesn’t have to be called start
  • DSL used to direct the flow, e.g. on(“submit”).to “end”

Domain Model

  • don’t have to worry too much about the domain model except for the object that’s used to track the conversation
  • Booking class is what’s used to track the conversation and isn’t persisted until the end
    • must implement Serializable in order to work

Creating a Controller and Actions

  • create a controller as per usual, but create an action ending with “Flow”
  • def bookingCartFlow = {
    start() {
    on(“next”) {
    // do work here
    log.info “inside start”
    }.to “stepA”
    on(“done”).to “end”
    }

    stepA() {
    on(“prev”).to “start”
    on(“done”).to “end”
    }

    end() {
    // define action state
    action {
    log.info “finish what you’re done with”
    }
    }
    }

  • make sure to follow the DSL–doesn’t necessarily error out if you aren’t following the DSL
  • examples here are all done in the controller but in a real app you’d be using a service layer
    • according to the docs transactional needs to be set to false, but it doesn’t work this way currently (1.1.1)
    • can do with transaction inside services if you’re trying to save states in a particular order

Views

  • in flows you can have subfolders below the view directory for the controller
  • class HotelController {
    def index = { redirect(action:’bookingCart’) } // this will go to the bookingCartFlow

    def paypalFlow = {
    pay() {
    on(“submit”) {
    log.info “Was it paid? ${params.paid}”
    }.to “evaluatePayment”
    }

    evaluatePayment() {
    action {
    if (params.paid == ‘yes’) {
    conversation.booking.paid = true
    return paidInFull
    } else {
    return paymentDeclined()
    }
    }
    }
    }

    def bookingCartFlow = {
    start() {
    action {
    log.info = “-start the booking-“
    }
    on(“success”).to “findHotels”
    }

    findHotels() {
    on(“showHotels”) {
    // find the hotel
    def hotels = Hotel.findAllByNameILike(“%${params.hotelName}%”, [max:10])
    [hotelResults : hotels]
    }.to “hotelListPage”
    }

    hotelListPage() {
    on(“view”) {
    flow.hotel = Hotel.get(params.id)
    }.to “hotelView”

    on(“back”) {
    }.to “findHotels”
    }

    hotelView() {
    on(“back”).to “start”
    on(“book”).to “bookingPage”
    }

    bookingPage() {
    on(“proceed”) {
    def booking = new Booking(params)
    booking.hotel = flow.hotel
    conversation.booking = booking
    if (!booking.validate()) {
    return error() // returns back to the page they came from and outputs errors
    }
    }.to “saveBooking”
    }

    saveBooking() { // the parens here are optional
    // no corresponding view to “saveBooking” so this is a decision node
    action {
    if (params.paymentType == “creditCard”) {
    return creditCard()
    } else {
    return paypal()
    }
    }
    on(“creditCard”).to “creditCard”
    on(“paypal”).to “paypal”
    }

    paypal() {
    subflow(paypalFlow)
    on(“paidInFull”)
    }

    creditCard() {}
    }
    }

  • to identify an event in a flow, you can use the name of a g:button as the event you want to trigger when the button is clicked
  • to use an event in a g:link, add event parameter to g:link, e.g. <g:link event=”view” … />

Scopes Available in Flows

  • request
  • params
  • session
  • flash
  • flow
    • lasts for the duration of the flow
    • removed when flow ends
  • conversation
    • lasts for the length of the flow and nested subflows
    • subflows are good for things like different payment methods–can be reused across multiple flows
  • best practice point: don’t refer to anything about flows or conversations in gsps
    • this ties the view to a specific flow or conversation and reduces the ability to reconfigure and reuse things

What are subflows

  • ability to create alternative flow paths
  • call subflows via flows
  • are their own flows themselves
  • name with “Flow” at the end
  • calling a subflow
    • subflow(subflowName)

Can you call to flows in different controllers?

  • yes, but it gets a bit funky
  • define flow in another controller as per usual, but declare the flow as static
  • in other controller, do def creditcardFlow = BillingController.creditcardFlow
  • still have to put the billing views under the hotel views as opposed to the billing views

How do you end the flow?

  • if a flow doesn’t do a transition or a redirect, the flow ends

Final thoughts

  • don’t call services with transactions–can cause unexpected problems
  • in grails 1.2 flows are a plugin
  • webflow moves objects from flash to request scope between transition states
  • don’t include the scope prefix when calling on the page
    • merge flow/conversation to local scopes

http://github.com/integrallis/grails_web_flow_demo

Session Notes – Grails for the Enterprise

Posted on by Matt Woodward

Presenter: Robert Fischer

What you’ll be getting for your time

  • j2ee friendly intro to grails
  • tour of grails functionality
  • practical day-to-day insights on using grails
  • live coding demo
  • argument for a single assertion: all enterprise web app development should be in grails
    • stunningly simple development
    • succinct code using a superset of java
    • sane defaults, straight-forward configuration
      • all the stuff you always use is pre-bundled
    • typing as deemed useful by developer
    • standard java deployment approach
    • springsource backed and here to stay
      • no need to worry about it going away
      • big community behind it that was around even before springsource acquisition

What is Grails?

  • web app dev framework and environment leveraging java and groovy
    • environment is often overlooked
    • easy to do development with vi and bash–need for IDE isn’t all that huge
  • convention-based mvc development framework
    • ruby on rails really introduced the idea of convention over configuration
    • grails takes this idea and applies it in the java space
    • powerful command-line tools
  • powered by pre-configured and pre-integrated spring, hibernate, sitemesh, junit, etc.
    • all the technologies you are or should be using

How would you like your grails?

  • conceptually think dynamic mvc framework
    • dynamic, succinct domain and controllers
    • view technology works naturally with html
    • run from source code check-out
    • new features via extensible plugin architecture
      • even the stuff built into grails is based on plugin architecture
  • actually approachable best-of-breed java stack
    • prepackaged java build system
    • builds a war to plug into existing deployments
    • hooks for existing spring and hibernate configs
    • support for other enterprise technologies

How does Grails fit the Enterprise?

  • what is the enterprise?
    • some people see this as “established, extensible, dependable”
    • some people see this as “bloated”
  • unique qualities of enterprise dev
    • large-scale apps with application ownership flux
      • people coding and gathering requirements on app will change over time
    • existence of user-developers
      • people who want/need to use your code but don’t want to know how the code works internally
      • google “robert fischer free toilet” to see his rant
    • out-of-control infrastructure
      • literal meaning: infrastructure I the developer don’t have control over
        • don’t have access to production databases, etc.
      • can also mean out-of-control in terms of there being a lot of different systems that the app needs to tie into

How does Grails fit in?

  • large-scale and ownership flux
    • conventional development
      • common style so doesn’t matter who wrote the code originally
    • built-in testing
      • strongly encourages writing of tests–major way to deal with ownership flux
    • groovy
      • more succinct language, easier to read
  • existence of user-developers
    • plugin architecture
      • “experts” can build plugins that “users” can leverage
    • direct java lib interaction
      • don’t have to think about how grails deals with the java class you just imported–it’s java
  • out-of-control infrastructure
    • big win here is Spring

Architecture of Grails

  • groovy
  • Model
    • GORM
    • Hibernate
      • can plug in other persistence mechanisms (JPA, Hadoop, CouchDB, etc.)
    • JDBC
  • View
    • GSP/Taglibs
      • taglibs are nice, straight-forward way to extend the codebase–much simpler than Java taglibs
    • sitemesh
  • Controller
    • Grails controllers
    • Spring MVC
  • pervasive
    • spring DI
    • spring transactions
    • servlet api
    • junit
    • ant (gant)
    • log4j
    • web.xml

Plugins

  • if you want other technology than listed above, there’s probably a plugin that does what you want
  • functional testing
    • G-Func, Canoo Webtest, Selenium, Fitnesse
  • RIA
    • Grails-UI, RichUI, GWT, Flex, YUI, IUI (for iPhone)
  • Database Management
    • autobase — runs database migrations
    • rails migrations plugin (you don’t want rails migrations!)
  • background tasks
    • BackgroundThread, Quartz
  • tons more — http://grails.org/plugins
    • rating system but don’t put too much credit in it

Autobase

  • manages database state using a non-linear collection of database change sets
    • Rails migrations are a linear path
      • assumes developer who made previous changes will be making future changes
  • leverages existing grails database automation to minimize effort
    • uses HBM -> DDL
    • HBM -> DDL assumes everything will be non-destructive
    • autobase handles destructive changes
    • uses embedded dsl in groovy; allows for things like dropColumn(), renameColumn()

BackgroundThread

  • provides a spring bean that executes arbitrary closures in the background
  • handles some awkwardness with hibernate sessions, provides thread logging and pooling

GORM Labs

  • transactional actions in controllers
    • services are transactional
  • .query — shorthand for .executeQuery
  • aggregate properties on domain classes
  • property errors on nested domain classes
  • human-readable messages

SubLog and Testing Labs

  • SubLog = Sublime Logging
    • static ‘log’ properties
      • by default logging is available only on instances of objects
    • dynamic ‘log’ properties
    • strips off slf4j and gives more direct access for log4j
  • testing labs
    • controller integration test case support

Your Grails Adoption Plan

  • start with a roughly green-field proof of concept web application
    • grails for reporting on an existing database is a great avenue for this
  • replace/supplement a service with grails
    • making grails an endpoint for an ESB
  • use GRAG on SourceForge to generate a db front-end
  • wrap an existing Java or PHP web app in grails and use web.xml (installed via “grails install-templates”) to map existing URLs to servlets
    • use url mappings to add new functionality in grails (e.g. http://myapp/g/newStuff)
    • PHP plugin gives you a PHP engine as a servlet–runs existing PHP code
  • do it and don’t tell anyone
    • ends up as a WAR
    • ask forgiveness later

Resources

  • live open source apps
    • Grails Crowd
    • grails.org
    • Groovy Blogs
    • Groovy Tweets
  • media
    • Groovy, Grails, Griffon podcast
    • GroovyMag

Live Coding/Q&A

  • anything you want to use in multiple apps, write as a plugin
    • grails generate-plugin PluginName
    • a plugin IS a grails application
      • only difference is it has a XXXGrailsPlugin.groovy file
    • plugin sizes are minimal addition to WAR files
    • once you’re done, do grails pacakge-plugin
      • creates a zip file containing the plugin
      • can do grails install-plugin zipfilename
    • need to set up a repository for plugins
    • when you go to production, it bundles the plugin into the war
    • note that plugins aren’t included in your application’s source–so need to point to a repository or figure out how to include those in source control
  • existing ant tasks can be plugged straight into gant
  • taglibs
    • easy to create and use
    • grails create-tag-lib taglibName
    • can take in attributes and the body between the opening and closing tag
      • e.g. def mytag = { attrs, body -> … do stuff … }
    • by default taglibs go into g prefix, e.g. <g:myTag/>
      • define a namespace in the tag library to give it a prefix other than g (static namespace = “whatever”)