> 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 [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/groups/opt_out.
