Hello all Wave in a Box uses a novel approach of rendering waves (code) named Undercurrent<http://www.waveprotocol.org/protocol/design-proposals/new-wave-panel-undercurrent>. In brief, Undercurrent renders the contents in several stages with potential to start with server rendered HTML and then to upgrade it with liveness and more features later on. Since WIAB is based on GWT, it is possible to use the same code for waves rendering both on the client and the server ( with limitation that the server can render only static content). Server side rendering can enable future exciting features like: 1. Rendering waves at least partially on the server side and then only upgrade with advanced features on the client side thus fully utilizing the Undecurrent potential and reducing the wave loading time to minimum. 2. Waves export to HTML feature - similar to Google Wave. 3. Exposure of shared waves as pure HTML served by the server so they can be crawled and indexed by external search engines.
However, currently the wave rendering code is tightly coupled with client side (DOM) code and makes direct use of GWT related features like resources injection using GWT.create(). So, I have prepared a patch to address this issues - it can be found at http://codereview.waveprotocol.org/583001/show Patch description: The goal is to separate xView/xViewBuilder classes (and dependencies) from the client side code to allow server side generation of the Undercurrent HTML. Changes: 1. All Undercurrent UI rendering related classes that don't import client side classes from GWT moved from src/org/waveprotocol/wave/client into src/org/waveprotocol/wave -src/org/waveprotocol/wave/client/common/safehtml -> src/org/waveprotocol/wave/common/safehtml -src/org/waveprotocol/wave/client/render -> src/org/waveprotocol/wave/render -src/org/waveprotocol/wave/client/uibuilder -> src/org/waveprotocol/wave/uibuilder -src/org/waveprotocol/wave/client/wavepanel/render/ShallowBlipRenderer.java -> src/org/waveprotocol/wave/render/ShallowBlipRenderer.java -src/org/waveprotocol/wave/client/wavepanel/view/fake -> src/org/waveprotocol/wave/view/fake -src/org/waveprotocol/wave/client/wavepanel/view/impl -> src/org/waveprotocol/wave/view/impl -src/org/waveprotocol/wave/client/wavepanel/view/dom/full/*Builder.java -> src/org/waveprotocol/wave/client/wavepanel/view/*Builder.java -src/org/waveprotocol/wave/client/wavepanel/view/dom/full/*ViewBuilder.java -> src/org/waveprotocol/wave/client/wavepanel/view/*ViewBuilder.java -src/org/waveprotocol/wave/client/wavepanel/view/*View.java -> src/org/waveprotocol/wave/view/*View.java (Similar changes for the test classes). 2. WavePanelResourceLoader class was changed to be an interface (and renamed into WavePanelResources). The actual client side resource injection happens now in GwtWavePanelResourceLoader. 3. Resource interfaces in xViewBuilder classes changed to be pure POJO interfaces, so they don't extend ClientBundle/CssResource anymore. 4. xViewBuilder classes changed to receive instance of WavePanelResources in the create/constructor methods instead of statically accessing as before. 5. GwtWavePanelResourceLoader initializes the resources with GWT.create() and then by using adaptor POJO interfaces passes them to the xViewBuilder classes. This also includes introduction of POJO WaveImageResource interface that mirrors the GWT ImageResource interface and an adapter class GwtWaveImageINterface that implements both WaveImageResource and ImageResource that have identical signatures. *Since the patch makes a lot of changes, I think everyone should be aware of the re-org. I also want to ensure that nobody has any violent objections to: * *) the change itself; or *) submitting it asap? Thanks Yuri