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.