Re: Generator - Best way to support custom user extension

Is it not easier to use the TypeOracle to find CustomFieldSerializer JClassType and get all its subtype with JClassType.getSubtypes() ? This way you can put your custom serializers anywhere with the name you like. 

I am not 100% sure but I think in older GWT versions a CustomFieldSerializer was just a plain class with static methods and these methods must have specific names so the generator can invoke them. There was nothing you could search for (except for a class name defined by convention). Don't ask me why they have chosen this design but I would guess it was just a performance reason for the serializers itself. Normally serializers are stateless and only have static methods so you don't need to instantiate them. Well and tagging these serializers with an interface doesn't make that much sense because an interface can not define static methods so you can't invoke them by only having the interface type.

 

I wouldn't use an annotation because a guava collection could be used by a large amount of classes so you only want to define the serializer once for a given collection type. To do so you would need some kind of a "configuration" class where you can put annotations once. Or use such a configuration class the google-gin way: 

void configure() {

  serialize(ImmutableSet.class).with(ImmutableSetJsonSerializer.class).

}

How do you give the configuration class to the generator ? With configuration property like below ?

And how does it work ? The generator get the full qualified class name, instantiate the class and get the configured serializer from the internal map ? Since it's a Class, you then use the TypeOracle to get the corresponding JClassType ?

Well GIN uses an annotation @GinModules where you reference these configuration classes (either by class or through a list of configuration properties that contain full qualified class names as already mentioned). Haven't looked at GIN source but I would guess they do what you said: instantiating the configuration classes found in the @GinModules annotation and use them as a model to tell the generator what to do. 

In your case I would use a hard coded configuration property to make the configuration class available to the generator. Users of your library could then extend that property.

 I didn't know you could do that in Gin, that's nice! (I'm already thinking how I could use that to split a big application I'm working on)

Yeah you could do nice things with such an approach. And just to be sure: such a property can really have multiple values:

<extend-configuration-property name="app.modules" value="com.example.AppModule1" />

<extend-configuration-property name="app.modules" value="com.example.AppModule2" />

 

For all these configuration methods, is there some built-in method inside generators to cache the configuration so you compute it only once ? I imagine creating a Map<JClassType, JClassType> (type -> serializer) and giving that map to some kind of compilation context.

Your generator should extend IncrementalGenerator which allows you to store information between generator runs. So you would typically store some data that allows you to validate if the cached JS output from the previous generator run can be reused or not. There are two (?) generators in GWT that are already IncrementalGenerators. Just do a reference search in your IDE and see how they work.

http://www.gwtproject.org/javadoc/latest/com/google/gwt/core/ext/IncrementalGenerator.html

Of course you could still choose the tagging interface strategy but I think it could hurt SuperDevMode in the future once the GWT compiler guys have finished their new incremental compilation mode for GWT. If you are interested in this new compilation mode and how generator implementations might affect it you better ask on the contributors list to get some input from the GWT compiler guys. I think the key point is that a generator should also work without having the whole world knowledge of the GWT application.

-- J.

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/groups/opt_out.