Question

One requirement in our application is to implement “dual control” for everything, including CRUD operations.
Just to be clear, “dual control” is a feature that requires a change in the data to be approved by someone other than the change requestor. So when a user make changes to data, it’s not directly committed to production tables. I’m aware of several ways to implement this (e.g. staging tables) but thats for other time.

The question, with such requirement, do you think we should follow the standard “data centric” way of generated Roo + GWT (which uses RequestFactory) ?

Or we’ll better off implementing our own “command pattern” based framework to support dual control?

I’m inclined toward the latter. My intuition (which based on 3 days play-around with Roo+GWT) says that RequestFactory is not designed with dual control in mind, and we’ll hit a wall if we try to force our way in. Would be more than happy to be proven wrong here.

Answer 1

Have you looked at RequestFactory’s ServiceLayerDecorator? It mediates all interaction between the payload processing and your domain objects and code. As an example, you could override the getProperty and setProperty methods to read from and write into some kind of “shadow” log that holds pending mutations.

If you need to implement ACLs for objects, methods, or properties, the loadDomainObject and resolveX methods can be used to control which server-side classes any given request can interact with.

To wire in a custom decorator, you can subclass RequestFactoryServlet and call the two-arg constructor. Alternatively, you can just instantiate a SimpleRequestProcessor using the object returned from ServiceLayer.create().

Implementation note: all of RequestFactory’s default domain-interaction behavior is built using a series of ServiceLayerDecorators; check out the GWT source if you want to see example code for building a ServiceLayerDecorator. One thing to note is that if your decorator calls any methods defined in the ServiceLayer API, it should use the instance provided by getTop(). ServiceLayerDecorator instances are expected to be stateless and reusable, so if you need to maintain state across method calls, consider using ThreadLocal variables, similar to RequestFactoryServlet.getThreadLocalX().