Hacking on GraphHopper - a Java road routing engine. Peter has posted 62 posts at DZone. You can read more from them at their website. View Full User Profile

Griffon + Remote GORM + X: Inspirations for the Best RIA Stack

12.08.2009
| 8538 views |
  • submit to reddit

Today I explain a possibility of a pure Java-based client/server application (the client side should be a Rich Internet Application) with a database backend.

I know that other people might already had this idea and others implemented this in a different way and Griffon is on the way, but let my explain it now in (more) detail. It is only an aggregation of existing tools.

How should it look like?

We simply replace the HTML-view of an ordinary Grails application with Griffon! So instead of a browser we will have the mature JVM and we could programm all in Java/Groovy! No JavaScript, no HTML, no CSS, no …!

(Ups. No CSS? Okay we could use css on the desktop, too)

Shouldn’t this be an easy task to replace the V in an MVC application? The problem lays in the detail. E.g. do we need the full GORM functionality on the client side (‘remote GORM’)?

The cayenne framework (a nice hibernate alternative) supports the so called remote object persistence which would be great for this kind of application. They use the hessian library to communicate over HTTP from the client ‘over’ the server to the database. So, the db-programming-style on the client is nearly identical to that on the server!

So, do we need Person.findByXY and all the other, useful methods on the client? I fear tweaking hibernate is necessary but maybe with some grooviness we could avoid this!?

Another simpler approach would be to use the already available services of Grails for the client side. With Xml (Un-)Marshalling or SOAP like it was done before? But hmmh, I prefer the cayenne way … its groovier!

So, what do we need for our 3 tier pure Groovy solution?

We’ll need Grails!

To be a bit more specific: we would actually only need the GORM plugin (and Spring) from the Grails project for the server to communicate to the DB and manage the migrations.

We’ll need Griffon!

We need the full Griffon stack for the client. And if we only use GORM from Grails we will use Griffon also on the server side, I guess.

So either GORM+Griffon+Griffon (db+server+client), which would be more consistent, or GORM+Grails+Griffon which could be easier to implement at the moment.

We’ll need Spring Rich Client!

We need some nice to have packages from the Spring Rich Client project for the client side: validation, window-docking, master-details stuff, …

We’ll need the Hessian Library!

Additionally to the GORM plugin we will need the Hessian library to easily (!) communicate between the client and server. (Short explanation: Hessian library is RMI without drawbacks.) Later on we could implement a remote GORM with the help of this library (see above)! Without this functionality we won’t have fun: either we can only implement a two tier applications (client+db) or the programming is as slow as it would be with an ordinary non-groovy desktop application (via SOAP etc).

We’ll need JavaFX!

Why do we need JavaFX if we already have Groovy as the UI DSL? Marketing! That would mean a broader audience and maybe some tiny  support of Sun ;-)

Another feature of JavaFX would be that designers could create good looking SwingUIs for us without knowing Java/Groovy.

From http://karussell.wordpress.com

Published at DZone with permission of its author, Peter Karussell.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Peter Karussell replied on Tue, 2009/12/08 - 3:23am

Greg Brown replied on Tue, 2009/12/08 - 8:23pm

How about a Pivot (http://incubator.apache.org/pivot) front end (possibly written using Groovy) that talks to a Grails back end via JSON/REST? Such a solution would require a much smaller software stack...

Peter Karussell replied on Wed, 2009/12/09 - 6:27am

> Such a solution would require a much smaller software stack...

Why? Because Pivot.size < (Griffon.size - Groovy.size)?

Greg Brown replied on Wed, 2009/12/09 - 4:43pm in response to: Peter Karussell

No - what I meant was that you might not need all the additional libraries you mentioned. Pivot was designed to address this type of use case, so you might find that it already provides many of the features you are looking for in other third party libraries.

I don't really know what your specific requirements are, but it might be worth a look.

Peter Karussell replied on Thu, 2009/12/10 - 3:22pm

Yes, Ok. I already took a (quick) look at pivot while listing some "RIAs".

I think I didn't found a feature overview to see if this could replace some cool libs of e.g. Spring rc.

BTW: there is a section calendar in the tutorial. Has pivot a separate calendar project ala bizcal or TimeFinderPlaner? This would be cool!

Peter Karussell replied on Thu, 2009/12/10 - 3:29pm

Hi again,

please don't ge me wrong. I appreciate every (open source) projects' effort and I think pivot has its users.

But for me xml as a UI DSL is a no go. I would like to use Java or Groovy for that (in rare cases JavaFX is ok).

Although this sounds really cool:

"for example, JSON data returned from a REST service is serialized into the same data structures used by a table view component to present data."

And does pivot support plugins?

Greg Brown replied on Fri, 2009/12/11 - 8:23am in response to: Peter Karussell

Re: bizcal, TimeFinderPlanner, I agree - a Pivot-based calendaring app would be cool. Haven't had the opportunity to build one yet, though. :-)

Greg Brown replied on Fri, 2009/12/11 - 8:38am

I think I didn't found a feature overview to see if this could replace some cool libs of e.g. Spring rc.

You are right - we probably need better documentation on the high-level features Pivot provides. The Platform Overview section of the tutorial contains some feature information:

http://incubator.apache.org/pivot/1.3/tutorials/platform_overview.html

You may also find the information in the Stock Tracker tutorial useful:

http://incubator.apache.org/pivot/1.3/tutorials/stock_tracker.html

for me xml as a UI DSL is a no go. I would like to use Java or Groovy for that (in rare cases JavaFX is ok).

You aren't required to use WTKX to build your UI - you can still use straight Java code, if you prefer (WTXK is just a "shortcut"). You can also use any JVM scripting language. In fact, there has been some recent discussion about providing a Pivot Builder for Groovy - look for more information on this in the next couple months.

And does pivot support plugins?

Not sure exactly what you are asking - what sort of "pluggable" behavior might you be looking for?

Peter Karussell replied on Fri, 2009/12/11 - 3:52pm

Thanks for your answers! I will take a look at this.

> Not sure exactly what you are asking - what sort of "pluggable" behavior might you be looking for?

So that I can ship the small main project but some users need pluginA some need pluginB etc.

Greg Brown replied on Sat, 2009/12/12 - 7:25am in response to: Peter Karussell

So that I can ship the small main project but some users need pluginA some need pluginB etc.

Pivot itself doesn't provide a plugin architecture, but a Pivot-based application could easily add one by using an OSGI framework, for example. Does that help?

Greg Brown replied on Sat, 2009/12/12 - 7:32am

FYI, most of the current site docs refer to Pivot 1.3. We're currently getting ready to release version 1.4. You can see some preliminary docs on Pivot 1.4 here:

http://incubator.apache.org/pivot/1.4/tutorials

http://incubator.apache.org/pivot/1.4/demos

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.