Mixing createAndBindUi (UiBinder) and runAsync

@gwt-team

The new features of declarative UI via UiBinder and code-splitting via
runAync of 2.0 are great, but don't seem to play together very well.

I am working on a large application where (almost) all of the UI is
wired via binding. When I look at soyc reports -- specifically method
dependency -- I notice that the entire UI is in the initial fragment
because of the createAndBindUi setup in all of the app's widgets.

You can guess that wrapping createAndBindUi in a runAync doesn't
really work because ui binding is at compile time and creates new
binder implementation classes for runtime. (An interesting artifact of
DevMode is wrapping createAndBindUi in a runAsync actually does work
because of the runtime hooks.)

The Aync Provider pattern (see
http://code.google.com/webtoolkit/doc/latest/DevGuideCodeSplitting.html#patterns)
appears to be one general way of dealing with code-splitting (albeit
the docs are a little light on full examples), but it doesn't seem
like this pattern will work with ui binding. Please correct me if I am
wrong here.

One approach that I am considering is to revert back to a programmatic
UI in my EntryPoint (ie, get rid of UI binding at the top of my app),
and wrap each main UI component in a runAsync. From there down the UI
hierarchy I can decide which UI bits use createAndBindUI and which are
created the old way but take advantage of code-splitting.

Are there any other approaches that might help me out?

Stuart

--

You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to google-web-toolkit+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.