Monday, December 10, 2007

Grails Eclipse Plugin, very basic functionality

The Grails generation utilities are designed to run from a system command line. But I keep running into folks that just don't want to go to DOS. They want a GUI. Well, someone has created an Eclipse plugin (which works with WDSc 7.0). It is available at:

http://www.groovy-news.org/e/page/axelclk?entry=eclipse_grails_plugin_very_early

Please don't forget to restart Eclipse with the clean option after copying the plugin to your Eclipse directory.
For WDSc users that means copying the downloaded org.codehaus.grails.eclipse.externaltools_1.0.0.jar file to
C:\Program Files\IBM\SDP70\plugins
Then ending WDSc and, in a DOS window:

cd C:\Program Files\IBM\SDP70
eclipse -clean


The plugin is invoked by right-mousing on your Grails project in Eclipse and selecting Grails.

It is limited to the following options:

  • Create Domain Class

  • Create Controller

  • Create Testsuite

  • Create Domain Class

  • Create Taglib

  • Generate Controller

  • Generate Views

  • Generate All

  • Create Webtest

  • Run Webtest

  • Test Application

  • Run Application



Note too that there's an issue with Run Application that you need to be aware of: While its output goes to the Eclipse console, clicking on the red square "terminate" icon does not stop the launched JVM, which prevents you from running the application again (you'll get a TCP/IP bind error as port 8080 is allocated to the JVM.)
A simple solution for this is to bring up Windows Task Manager (with Control-Alt-Delete,) click on the Processes tab, find the image name of Java (you can sort by clicking on the Image Name tab,) select java.exe, and finally click the End Process button.
If you have multiple java.exe processes listed, be careful because you may terminate a process that's doing something that you may not want to terminate.

Friday, November 30, 2007

Grails template for Web-enabling RPG

The Grails Utilities for System i includes a utility to generate RPG call beans from SQL External Stored Procedures that are implemented with RPG. The utility creates both Java classes and Groovy classes. There is a Groovy and a Java class that wrappers a call to the stored procedure and there is (currently just Java) a class wrapper for the returned result set. The generated Java code can then be used in Java applications and the Groovy (and Java) can be used in Grails apps.

I'm planning on, first of all, adding the Groovy class wrapper to hold the result set values. But also I'm going to add the generation of a Grails domain class to hold the input parameters for the RPG call bean class (which calls the stored procedure.) The idea is that then it will be easy to generate a GSP prompt for the input parameters. Also, the generated domain class will have Grails constraints to validate user input.

But, you ask, isn't a domain coupled with a table? Only if you use the domain CRUD methods. What I do is use domain.validate() to use Grails' fantastic validation feature then call the RPG call bean.

So, going the extra mile (which, with Groovy is really only a couple of yards,) I plan on extending the tools with:

  • A domain class generator, that will also gen constraints for user input for RPG parameters

  • A controller template to generate Grails actions to invoke the Groovy RPG Call beans

  • A GSP template to generate an RPG Call Bean prompt form and a result form



While the generated code and GSP will function, in practice it really wouldn't be used in production. Rather you'd use it to test your RPG invocation and to have example, runnable code that can be refactored into production quality applications.

Thursday, November 29, 2007

Groovy Futures

I wanted to provide a bit of history going back to Spring 2007 when I first realized that the language called Groovy and the framework called Grails had bright futures. I kept hearing about Groovy on various technical podcasts (such as The Java Posse so I started to look curious about this new language. Then I listened to a podcast by Scott Davis The Groovy Programming Language and Scott convinced me that Groovy was indeed, as it's name suggests, pretty cool.

So I began to listen to all the podcasts I could find on Groovy and Grails. The Grails Podcast provided plenty (it now has 50.) Another site that has a number of great Grails Podcasts is About Groovy. My favorite is Neal Ford's

I also began to play with Groovy and Grails. I did what everyone should do and ran the Quick Start and then a couple Tutorials.

My timing was pretty good because four books on Groovy and Grails had just become available:


Groovy in Action is my favorite. Java developers should read that book cover-to-cover. Non-Java developers need only read, initially, through chapter 6. Then read the rest of the book after they've worked with Groovy for awhile.

The Definitive Guide to Grails is just what it says. It was written by the creator of Grails. I would recommend that you read Chapter 1 and Chapter 2 of Groovy in Action before reading The Definitive Guide to Grails as the Groovy intro in the in action book is very well written.

Getting Started with Grails is tutorial based. Jason Rudolph does a very nice job. You might even read this before working your way through The Definitive Guide to Grails

Groovy Programming was written as a college text and, while thorough, it is a bit boring.

Anyway, after reading all the books and doing the various tutorials and playing with some ad hoc applications, I started to work with System i legacy database tables. And I ran into a few issues. I've resolved those issues, using the Groovy language and the Grails philosophy of "convention over configuration." I developed several tools and launched an open-source project Grails400Utils: Grails Utilities for the IBM System i

I published an article The Search for the Holy Web Development Grail(s) in the November issue of System i News. And I did my own Groovy and Grails podcast What's in a name: Groovy and Grails - The implementation, language and more

I've also developed and deployed two Grails applications that are now in production. I am currently working on three other commercial Grails applications.

The future for me is Groovy (and Grails) and I'm continuing to develop the Grails Utilities for the IBM System i while being billable doing GonG development (although I can still be coerced to do Java coding.)

Sunday, November 18, 2007

Blog start

My initial post. In this blog I intent to track my work as I investigate new technologies, specifically Groovy and Grails. I will be back-tracking in time to spring where I first became enamored with the hot new Groovy language and the Grails web framework.