Using ocmgroovy as Persistance Layer for Griffon

Griffon is a very interessting approach to create an agile and fun framework for building Swing applications. Currently a very shy version numeration is used (0.0.1 is current), but the whole package is built using large know-how.

One thing missing is the persistance layer. It is planned to use GORM, the hibernate-based layer of Grails.

This situation is an opportunity for ocmgroovy, my "framework"(*) for persisting Groovy objects into a JCR. While beeing a little ugly hack atm, the basic things like save() and get() seem to work, at least for my basic test cases.

Using ocmgroovy in grails is one annoying and 2 easy steps

1. download ocmgroovy (either create the project via pom.xml or download all dependencies manually, which basically means to download all jackrabbit dependencies and xstream with its dependencies) and install it into {griffon_project}/lib directory
2. declare the class to be persisted in {griffon_project/lifecycle}/Startup.groovy
3. use it in your Griffon mvc
   

Step 2 looks like this

TransientRepository repository = new TransientRepository()
def session = repository.login(
new SimpleCredentials("threatmanagment", "password".toCharArray()))
JcrPersister strategy = new JcrPersister()
strategy.session = session
strategy.instanceRoot ="threatmanagment"

strategy.instrumentate(ThreatModel, "name")
strategy.instrumentate(Dataflow,"id")

This makes model classes ThreatModel and Dataflow persistable, i.e. currently mostly adds save() and get() methods to instance and class, respectively

And Step 3: about as easy

ThreatModel model = new ThreatModel("name": "TestModel")
model.save()
...
ThreatModel model2 = ThreatModel.get("TestModel")

Please note that this is all very shaky at the moment (and therefore will create a black hole if you try it at home ;)), but might prove usable in the future.

I probably will release a PoC-project in the near future.

===
(*): ocmgroovy is very alpha and only used by myself. Therefore I do not consider this to be a framework

Grails, Flex, Soap

Today I have written a small PoC for Grails, Flex, SOAP. The initial task was (and still is) to find out which communication takes place in a Flex application.

Having no clue about Flex, a little understandig of Web Services and some minor understanding of Grails, it took me no more than 3 hours, including googling for web service usage in Flex and hunting of really stupid beginners bug.

This shows the real muscles of Grails and its really awesome plugin ecosystem.


grails create-app HelloFlex
cd HelloFlex
grails install-plugin flex
grails install-plugin xfire
grails create-service hello

Ok, everything needed is installed. 2 more things to do. in HelloFlex\services\HelloService.groovy:

class HelloService {
static expose=['xfire', 'flex-remoting']
def hello(String echo) { return echo.reverse() }
}


Note the use of expose: this service is both available via flex-remoting and via SOAP.

Second: create HelloFlex\web-app\test.mxml


<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml">
<mx:WebService
id="userRequest"
wsdl="http://localhost:8080/HelloFlex/services/hello?wsdl">
<mx:operation name="hello" resultFormat="object"
fault="mx.controls.Alert.show(event.fault.faultString)"
result="showResult(event)"/>
</mx:WebService>
<mx:Script>
<![CDATA[
import mx.rpc.events.ResultEvent;
import mx.rpc.events.FaultEvent;
import mx.controls.Alert;
[Bindable] private var passage:String;
private var options:Object = {"output-format": "plain-text"};
private function showResult(e:ResultEvent):void {
passage = userRequest.hello.lastResult;
}
private function send_data(input:String):void {
userRequest.hello(input);
}
]]>
</mx:Script>

<mx:Text text="Echo Service" fontSize="16" fontWeight="bold"/>
<mx:Text text="Input" fontSize="12"/>
<mx:TextInput id="lookupPsg" textAlign="center"/>
<mx:Button label="Submit" click="send_data(lookupPsg.text)"/>
<mx:TextArea height="352" width="590" id="psg" text="{passage}" editable="false" fontSize="11"/>
</mx:Application>

(sorry for the mess, dunno how to format this better )

Hitting http://localhost:8080/HelloFlex/test.mxml displays the Flex application which uses SOAP protocol to consume the webservice.

Built on the shoulder of giants...

Update 12th Jul: Marcel Overdijk has already written a similar (well, actually better:)) example back in january.

Grails & GWT: an uneasy match?

Currently I am looking for the holy grail for AJAX-enabled Grails development. While trying out the excellent GWT-Plugin, something occurred to me: there are 3 programming languages involved: Groovy for Grails and Java/JavaScript for GWT.

One could argue that Javascript is transparent while using GWT. I would agree to a certain point with this, because I do not know how fast you need to touch Javascript in GWT.

Still this leaves me with 2 languages, namely Groovy and Java. While those 2 languages are very close together, this situation reminds me of a brilliant comic.

So why not use Groovy and Javascript, i.e. directly use one of the excellent Javascript frameworks? It does make more sense, since both are dynamic languages and both get more and more IDE support, namely in that one that costs some (you get the idea...).

Still: 2 languages is still one too much. Since Javascript is set on the client, this means to use, well Javascript on the server too. The guys creating the Sling framework for example do exactly this: it is up to you to use the Sling API on the client or server-side. I am not sure wether the code is 100% the same, but the general direction is given...

I still go with groovy, call me old-fashioned...

update:

Maybe the strangest thing in GWT/Grails combination is the fact that everything sent to the client has to be IsSerializable. And has to be retrieved via a Service.

Contrasting this with the direct use of a JSON builder which creates a format directly consumable by all Javascript libraries. Nothing beats

render DomainClass.list as JSON

update 2:
The last "update" is of course complete crap, see the comments! I was still in a kind of prehistoric knowledge level, GWT-wise.