gwt-dispatch and gwt 2.0 codeSplitting
federico
i have a problem with the new codeSplitting feature of gwt 2.0, when i
combine this with the "command pattern" approach of gwt-dispatch to
make calls to the server.
The fact is that on the client side the DispatchAsync instance that is
used to perform server calls make all the possible Actions and Results
to be reachable from the initial EntryPoint class.
And this force all the possibli serializable Actions and Results
implementations to be included in the initial code fragment.
I'm really tryng to avoid this because each client module define it's
own Actions and Results and i'd like this classes being downloaded
only when the module that defines it will became reachable.
David Peterson
I'm yet to touch GWT 2.0 and it's code splitting features. I think some others on the list may have already had a go, but I'm not sure.
You could try providing your 'DispatchAsync' as a Provider<DispatchAsync> instead - that may decouple it enough for code splitting to work.
Also, technically DispatchAsync doesn't have to be a singleton. The DispatchServiceAsync, probably, but GIN doesn't have to know about that...
Anyway, I'd be interested to hear how you go. Let us know if you make any progress.
David
federico
thanks for the quick response
i understand what you say but i see a problem:
also if the we succeed in loading the DispatchAsync in a deferred way
and not on the initial fragment
i think it's still a "all or nothing solution", in the sense that the
from the DispatchAsync instance all the
possibles Actions and Results of the applications are reachables, id'
like to find a way to split
Actions and Results implementig classes among the code fragments of
the application modules but all this classes get in
the fragment that contains the DispatchAsync implementation.
Anyway, i'll make some trys in the next days..
Federico
federico
I did some tests but i've not found a solution to this problem.
I've got a sample project to show my tests if anyone is interested.
To summarize I understand that if we have an rpc service with this
kind of signature:
public <R extends Result> R execute(Action<R> action);
then "code splitting" loose all it's advantage, in fact it will put in
the same fragment
the loading of the rpsService and all the possible Action and Result
so if you have a big application with potentially lots of Action and
Results implementations,
this fragment will eventually become too big and you can't do anything
to split it.
To me this seems to be a problem with the gwt compiler that didn't
fully understand the semantic of the signature:
public <R extends Result> R execute(Action<R> action)
seems that it didn't rely on the constraint that the possible types
returned from a call with
a Action<R> parameter are only subtypes of R and not subtypes of
Result.
