[errai-dev] Errai vs. RequestFactory - where to go?

Thomas Frühbeck fruehbeck at aon.at
Sun Apr 28 13:51:00 EDT 2013


Hi,

I have been working on a CRUD-enabling plugin for Forge some time ago 
and have been immersed in a real world project using it's outcome for 
some time (Jonathan Fuerth has been discussing it already).
While trying to find a useful abstraction for the persistence bridging 
code I totally overlooked GWT RequestFactory, which seems to provide an 
interesting framework for CRUD applications.

IMHO the most important points:
     - an EntityProxy interface and along with it an EntityProxyId
     - client side RequestContext for instantiation and lookup
     - an extensible server side instantiation and lookup framework
     - a transportable/queuable abstraction for entity changes

These are IMHO indispensable to bridge to ORM because GWT imposes too 
many restrictions on the classes/code it can handle.
I have had an intensive look at the code to find a reason for Errai 
_not_ to support this part of GWT, and I think that Errai is nearly there.

- Interfaces: ObjectBuilder and ClassBuilderTest show, that an 
implementation of new <Interface>() {} is prepared already to great extent
- server side lookup: would be implementable as kind of server side 
"second pass" DefinitionsFactory.loadCustomMappings - I did it by 
hooking statically into custom MappingDefinitions

It is yet unclear for me how a client side RequestContext could look 
like, if it should work transparent and annotation driven.
Ditto for EntityChange events.

I read in a blog comment by Mike Brock, that you do not plan to support 
RequestFactory.
Can you please provide some insight why you do not want to go that route 
and what kind of alternative you are working on?

Best regards,
Thomas


More information about the errai-dev mailing list