n a J2EE/GraniteDS platform where all the entities on the client side are generated with the graniteds-generator, we felt the need to give the developers of the client part a set of preconfigured remote objects, on which they could use code completion and parameter type to ease the use of remote services. The best candidate to carry out this job was of course the graniteds-generator, providing in it the right support of some new classes.

My coworker Saverio Trioni (saveriotrioni@me.com) and me developed what seems a quite good solution, that I hope you could consider to integrate into the main development line. In that case, I would be thankful if you would credit both of us, not only me, for the contribution.


As for the modifications we send in, a Service Bean annotated with @RemoteDestination will be translated into a subclass of ...mxml.RemoteObject, in which there is
1) an initialization method, where the channel/destination/etc. info provided in the server side annotation is used to connect to the right channel
2) one method (with the correct type for the parameters) for each method in the Service Bean, which calls the remote operation
3) two methods to add and remove listeners to the operations, which take a Function object as first argument and then add or remove the listener to the operation corresponding to the passed Function (which should be a method of the same object)

Example use of the "add listener" method (suppose PersonServiceBean.as is generate and there is a method getAllPersons() ):


var svc:PersonServiceBean = new PersonServiceBean()
svc.addOperationListener(svc.getAllPerson, ResultEvent.RESULT, handlerFunction)


To add a listener over all the RemoteObject just use the standard notation, as it is really a RemoteObject.


Note: The @RemoteDestination annotation must be added to the granite-generator-share.jar package for the builder to support this configuration. (done in main graniteds project)


I attach an archive of all the modified files, and the output of translating the PersonServiceBean in the graniteds_ejb3 example project.


==================================================

Explanation of the modifications:


== org.granite.generator.as3.reflect.JavaRemoteDestination

This is the only new class, that is a subclass of JavaAbstractType like the others in the package.
This class ignores the properties and attributes, collecting just the methods as they are, with full parameter information, and also stores the as3 types for all teh parameters.


== org.granite.generator.as3.reflect.JavaMethod

Heavy modifications are done on the JavaMethod class, because for service methods we need to store much more information than for javabean accessors. So a new constructor is made available which, if passed a JavaTypeFactory as argument, stores parameter types in both java and as3 in the class.


== org.granite.generator.template.remote.gsp
== org.granite.generator.template.remoteBase.gsp

New templates


== org.granite.generator.as3.reflect.JavaType
== org.granite.generator.as3.reflect.JavaAbstractType
== org.granite.generator.as3.JavaAs3GroovyTransformer
== org.granite.generator.template.StandardTemplateUris
== org.granite.generator.ant.AntJavaAs3Task
== org.granite.builder.properties.GraniteProperties

Slight modifications to take into accout the new category of translatable classes and the new templates.


Regards
Francesco