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

Reply via email to