Andres Almiray presents "Flying with Griffon" at SacGRU tonight

Andres Almiray will be doing a presentation tonight on Griffon at the local SacGRU (Sacramento Groovy User's) meeting. Please attend if you would like to learn Java Desktop Development "for Mere Mortals". Meeting details and the presentation blurb are below:

Thursday March 4 at 6:30.

Quilogy
2880 Gateway Oaks Drive, Suite 350
Sacramento, CA 95833

Flying with Griffon

Building a desktop application is a hard task, there are some many things to keep track of that many projects simply fail to meet their goals. Setting up the project structure keeping each artifact on a well identified location given its responsibility and type, defining the base schema for managing the application's life cycle, making sure the build is properly setup, and more. These are recurring tasks that should be handled by a tool or better yet, a framework. Griffon is such a framework. Inspired by the Grails framework Griffon aims to bring the same productivity gains to desktop development

Intellij 9 EAP fix a number of Groovy and Grails issues....

In case anyone has been using Intellij Idea 9 and been having issues with Groovy/Grails (for instance importing an existing project) I noticed that the latest 9 EAP (93.67) has a number of fixes. I haven't tested for myself yet whether or not It has fixed my particular issues but it's worth a try...

Strong Groovy

Usually Groovy is thought of as a loose, dynamically typed language that is otherwise similar to Java. Given this, it would make sense to write in Groovy when dynamism is needed an write in Java when you need strong typing, etc. to avoid side effects. But a great differentiator for groovy over any other dynamic language running on the JVM is that it also has all of Java's support for Strong typing, Generics, immutable objects and the like. This allows Groovy a tremendous range using dynamism where it makes sense and locking it down where it makes sense to do that.

Recently I found myself looking for a solution for Value Lists for using in my HTML Select fields. Initially I went for quick and dirty and created a utility class (a singleton) with a bunch of "value" lists. Literally lists of NameValue objects with a corresponding java class like:


public class NameValue {
private String name;
private String value;

public NameValue(String name, String value) {
this.setName(name);
this.setValue(value);
}

@Override
public String toString() {
return getValue();
}

public String getName() {
return name;
}

public void setName(String name) {
this.name = name;
}

public String getValue() {
return value;
}

public void setValue(String value) {
this.value = value;
}
}


I'm not sure why I used Java for this considering it was a grails project, but the class would have read better in groovy:


class NameValue {
String name, value

@Override
public String toString() {
return this.getValue();
}
}


Then I used my Singleton class to populate the lists as so:


public class ValueLists {
private static ValueLists ourInstance = new ValueLists();

public static ValueLists getInstance() {
return ourInstance;
}

private List approvals = new ArrayList();

public List getApprovals() {
return this.approvals;
}

approvals.add(new NameValue("1", "Yes"));
approvals.add(new NameValue("0", "No"));
approvals.add(new NameValue("2", "Exempt"));
}


While we're at it.... why not redo this class in groovy:


class ValueLists {
private static ValueLists ourInstance = new ValueLists();

public static ValueLists getInstance() {
return ourInstance;
}

private List approvals = [
new NameValue(name: "1", value: "Yes"),
new NameValue(name: "0", value: "No"),
new NameValue(name: "2", value: "Exempt")
]
}


Now I can use my Value Lists in my grails app like so:


<g:select name="approval" from="${ValueLists.instance.approvals}" optionkey="name"/>


Simple enough but it occurs to me that the ValueLists ought to be immutable as the lists should never change. It would then look like:


@immutable final class ValueLists {
private static ValueLists ourInstance = new ValueLists();

public static ValueLists getInstance() {
return ourInstance;
}

private List approvals = [
new NameValue(name: "1", value: "Yes"),
new NameValue(name: "0", value: "No"),
new NameValue(name: "2", value: "Exempt")
]
}


"approvals" (and any other properties) is now treated as private final with a getter. So my unwary teammates cannot override it. In addition, "approvals" is wrapped by an immutable wrapper class so my teammates can't get the list of NameValues and change it.

Of course if you've been working with Java 1.5 or newer for any significant amount of time it probably would have occurred to you that you could have used java's language support for enums. Well, no need to drop down to Java for this. My new Groovy Object is as follows(Approval.groovy):


enum Approval{
Yes("1", "Yes"),
No("0", "No"),
Exempt("2", "Exempt")

final String value
final String key

Approval(String key, String value) {
this.value = value
this.key = key
}

String toString() {
value
}
}


Now following this pattern I can code up all my grails selects as follows:


<g:select name="approval" from="${Approval}" optionkey="key" optionvalue="value"/>


The point is that Groovy is a Strongly typed language as well as it is a Dynamically typed language.

SacGRU (Sacramento Groovy Users) first meeting tomorrow

The Sacramento Groovy Users will be having their first meeting tomorrow at Quilogy. Please come by and meet other enthusiastic Groovy/Grails/Griffon/Gradle/GPars users.

Quilogy
2880 Gateway Oaks Drive, Suite 350
Sacramento, CA 95833

6:00 - 9:00 P.M.

Hope to see you there!

Integration Testing Grails Controllers

If you are planning on running integration tests on your Grails controllers it would be good to know how to test your controller regardless of whether it simply returns the model or uses the render method.

When your controller returns a model you can simply test the return type.

Given:

def show = {
def bookInstance= Book.get( params.id )
return [ bookInstance: bookInstance] }
}


You test it by:

def model = myController.show()
assertNotNull model.bookInstance

or some such.

If you use the render method in your controller then you would use the ModelAndView object in your controller.

Given:

def save = {
def bookInstance = Book.get(params.id)
render(view:'create',model: [ bookInstance : bookInstance ])
}

You can test it as follows:

bookController.save()
assertNotNull bookController.modelAndView.model.bookInstance

There is one nasty caveat to the render method, and that is if you are rendering a template instead of a view. This is common when you are doing AJAX type calls that only return a partial page. The problem is that Grails will not populate the modelAndView map at all. Nor does render provide a return type.

The answer came from the following mailing list posting:

http://www.nabble.com/Testing-Controller-with-render(template:....)-td18757149.html

Essentially you need to alter the behavior of the render method. You can do this in the setup as follows:

def renderMap

protected void setUp() {
super.setUp()
BookController.metaClass.render = { Map map ->
renderMap = map
}
}

Then Given:


def bookSummary = {
def bookInstance = Book.get(params.id)
render(template: "bookSummary", model: [ bookInstance : bookInstance ])
}


And then you test your model values as follows:

bookController.bookSummary()
assertNotNull renderMap.model.bookInstance

I hope this is helpful.

Happy Grailing!