Spicefactory – Part 1: Spice IT up, with Parsley, Cinnamon and Pimento

In my article on InfoQ I’ve looked into how Grails and Flex can be combined to create a rapid application development platform. I think this is one of the most promising combinations for RIA development at the moment. The Flex space is very happening and there are many initiatives going on. A few days ago I encountered this one on the web: https://www.spicefactory.org/. Apart from the funny name, I think it is a very interesting initiative, because it brings some new concepts to the Flex remoting mix.

Parsley
This is an IOC implementation inspired by Spring framework. On the official site, it is compared with Cairngorm. Without even trying it, I think I already like it better to Cairngorm. For me, Cairngorm is a bunch of very good ideas, with hardly any implementation to support it. Parsley, like Spring, seems more a lot of good ideas with some implementation to support it. Testing how this actually works is high on my todo list.
Cinnamon
This is a remoting framework, that is completely based on AS3 and Java. No Flex classes are used. It does use AMF, the fast serialization technology for AS objects. Furthermore it uses a Servlet to communicate with the server-side. While reading the documentation I started to wonder why this would be better than using Flex’ remoting service. I guess when you are using SWF without flex, this is a suitable choice.
Nevertheless I tried to expose my Grails services using this framework. This should be possible by using a custom configuration processor. While implementing this, I ran into the problem that Cinnamon requires your service to implement an interface. Since Grails services only have implementation, this is where my attempt failed.
Pimento
Now this is something completely different: Pimento offers to use the JPA EntityManager from the client-side code directly. So, from within your flex application, you can load, query and manipulate data from the database using JPA. To me this sounds… interesting.
When configured correctly to work together with Grails, which I’ll cover in the next blog, an application to manipulate data with Flex becomes quite trivial. Let’s say we have the following domain class is Grails:

import org.spicefactory.pimento.config.Operation;
@org.spicefactory.pimento.config.Managed(operations=[Operation.ALL])
class Person {
    def String name;
    def int age;
}

This is a fairly normal Grails domain class, except that it has an annotation, that configures pimento to allow data manipulation on this class.
This class is mirrored in the client-side code like this:

package
{
    [RemoteClass(alias='Person')]
    public class Person
    {
        public var id:Number = 0;
        public var version:Number;
        public var name:String;
        public var age:Number;
    }
}

Duplicating this class is still necessary. It should be rather easy to generate this class from Groovy code. Notice how the fields id and version that are automagically added by Grails are copied to the ActionScript class as well.
The rest of the client side might look something like this:

private function initEntityManager () : void {
  var config:PimentoConfig = new PimentoConfig();
  config.serviceUrl = getWebContextRoot(application.url) + "service";
  trace('url: ' + config.serviceUrl)
  config.defaultTimeout = 5000;
  config.configure();
  entityManager = config.entityManager;
}
private var entityManager:EntityManager;
[Bindable]
private var people:ArrayCollection;
private function refreshPersons () : void {
  var q:Query = entityManager.createQuery("from Person where age between :minAge and :maxAge");
  q.setNamedParameter("minAge", uint(ageFilter.values[0]));
  q.setNamedParameter("maxAge", uint(ageFilter.values[1]));
  q.getResultList().addResultHandler(onRefresh);
}
private function onRefresh (result:Array) : void {
  this.people = new ArrayCollection(result);
}

See how the client directly loads the data from the EntityManager! Similarly the client can update and delete data directly.
Now what do you think of this approach?
On the PRO side:

1. Writing a lot less code: No DAO required. No service layer that just delegates to the DAOs.
2. No lazy-loading issues: The client is in control and can load what is necessary.
3. Better feature packing: All (or most) code that is required for a feature is in client code.
4. …

On the CON side:

1. Very crude access control: Operations can be allowed/disallowed per entity.
2. Data access code (although EJBQL) scattered through (client) code.
3. No clear separation of concerns: Very data centered and data driven application.
4. …

Any thoughts?