@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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
