Generics inside method signatues of domain classes used by RequestFactory?

[Elhanan]

hi..

assume i have the following domain classes;

region which has a set of

Country which has a set of 

Location 

while although each one has different set of properties, all implement a common interface of 

Node<T extends Serializable >{

Public T getId(); // Region has long id, while Country has String id

public String getName(); // they all have a name to present them

public Collection<? extends NodeModel<? extends Serializable> getChildren() // must have wild card for different types of children.

}

now assume i wanted to have a RequestFactory method to get all the regions, but get them as NodeModel not as regions, so i would have a client code traverse through them like a tree...

problems is i understand i cannot use proxies for domains who have Generics in their methods signatures becouse RequestFactory can't validate them .

[Thomas Broyer]

If you're really sure about what you're doing, you can annotate the property with @SkipInterfaceValidation; and if you need to generate the DeobfuscatorBuilder yourself, possibly throwing in a ServiceLayerDecorator to help a bit.

That's what I'm doing right now, because of some customizations we have to do on the server-side.

In your case, the annotation might be enough (properties are not in the DeobfuscatorBuilder, only classes and service methods).

[Elhanan Maayan]

do you have any examples on DeobfuscatorBuilder and ServiceLayerDecorator  ?

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.

To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/q0xn7DMITY0J.

To post to this group, send email to google-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.

[Thomas Broyer]

A DeobfuscatorBuilder must be named the same as your RequestFactory (including same package) suffixed with "DeobfuscatorBuilder", and extend com.google.web.bindery.requestfactory.vm.impl.Deobfuscator.Builder.

The ones generated by the ValidationTool/annotation processor initialize themselves in the instance initializer. but you could do the same in the constructor. Initialization is made in three parts:

• withOperation: registers service methods
• withRawTypeToken: registers each proxy with their type token
• withClientToDomainMappings: registers the mappings between domain classes and proxies, i.e. domain-to-client (sic!)

Ex:

withOperation(new OperationKey("<token>"),

   new OperationData.Builder()

      .withClientMethodDescriptor("(<JNI descriptor for method arguments>)<JNI descriptor for return type; Request or InstanceRequest>")

      .withDomainMethodDescriptor("<similar, but for the corresponding domain method>")

      .withMethodName("…")

      .withRequestContext("…")

      .build());

The OperationKey can be built either with the token directly or the RequestContext binary name, method name and client method descriptor (the exact same arguments you'll pass to withRequestContext, withMethodName and withClientMethodDescriptor). For instance, I compute the token (using the 3-args ctor and then a call to get(): new OperationKey(contextBinaryName, methodName, methodDescriptor).get()) at the time I generate the DeobfuscatorBuilder.

withRawTypeToken("<token>", "<proxy binary name>";

The token is computed using OperationKey.hash("<proxy binary name>").

withClientToDomainMapping("<domain class binary name>", Arrays.asList("<proxy binary name>", "<another proxy binary name if needed>"));

Note that, in the DeobfuscatorBuilder generated by the ValidationTool/annotation processor, the BaseProxy, ValueProxy and EntityProxy do have their withRawTypeToken, and the latter two are listed as client types for java.lang.Object in withClienttoDomainMapping. So you'll have at a minimum:

withRawTypeToken("FXHD5YU0TiUl3uBaepdkYaowx9k=", "com.google.web.bindery.requestfactory.shared.BaseProxy");

withRawTypeToken("w1Qg$YHpDaNcHrR5HZ$23y518nA=", "com.google.web.bindery.requestfactory.shared.EntityProxy");

withRawTypeToken("8KVVbwaaAtl6KgQNlOTsLCp9TIU=", "com.google.web.bindery.requestfactory.shared.ValueProxy");

withClientToDomainMappings("java.lang.Object", Arrays.asList("com.google.web.bindery.requestfactory.shared.EntityProxy","com.google.web.bindery.requestfactory.shared.ValueProxy"));

An "echo" method could be:

withOperation(new OperationKey("com.example.shared.EchoContext", "echo", "(Ljava/lang/String;)Lcom/google/web/bindery/requestfactory/shared/Request;"),

   new OperationData.Builder()

      .withClientMethodDescriptor("(Ljava/lang/String;)Lcom/google/web/bindery/requestfactory/shared/Request;")

      .withDomainMethodDescriptor("(Ljava/lang/String;)Ljava/lang/String;")

      .withMethodName("echo")

      .withRequestContext("com.example.shared.EchoContext")

      .build());

But as I said, in your case, annotating the property with @SkipInterfaceValidation should be enough, and the ValidationTool/annotation processor will then generate the DeobfuscatorBuilder (because it won't check the domain class for that property). And it should work at runtime because properties are resolved by name, they're not obfuscated.

[Elhanan Maayan]

ok, when does one find such information, i mean, clearly these kind of things, even SkipInterfaceValidation do not appear on the developer guide, is there a secret cabal of gwt-isters, gathering somewhere in the ether?

--

You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.

To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/_GgAs2lW8gYJ.

[Thomas Broyer]

Reading the code is the best source of information (and my only source of information)