Gizmox > Solutions > Visual WebGui > The VWG Concept > Multiple Presentation Layers
         
 

Multiple Presentation Layers 

 

 

Decoupling the presentation layer from server application logic makes it possible for Visual WebGui to be presentation device agnostic. Visual WebGui application can be consumed by any device that can send & receive XML and draw UI.

The following diagram illustrates the decoupling of Visual WebGui server from the presentation layer and the outcome of this nature:

Multiple Presentation Layers

Visual WebGui Decoupled Presentation Layer

Two major characteristics make it possible to consume Visual WebGui from any device that can send and receive XML:

Generalized Object Model
A Visual WebGui control consists of two major parts:

  1. Server code – the UI logic of the control which might be affected or might affect the other UI on the screen or even the business logic of the application. For example: events handling – when an event handler is defined then the control has to.
     
  2. Client code – the part of the control which is responsible for rendering it (completely or partially) and applying behaviors – the part of the control which is responsible for pure client behaviors (such as styles, hover and visual drag ability).

Decoupled Presentation Layers

The clear cut separation described in the image above generalizes any control and UI when the Server code is the “Generalized Object Model” and the client code is responsible for a single task of rendering and maintaining the shown UI balanced according to the server state.

The server code responsibility is ended on the “rendering” part. As opposed to WinForms control which is assembled of both the logic and the rendering part, Visual WebGui control’s server rendering part is simply adding the metadata of instructions for the actual rendering on the client side. For example, follows a piece of the server code relating to ImageSize of a PictureBox:

Server Code 

public PictureBoxSizeMode SizeMode
{
    get
    {
         return menmPictureBoxSizeMode;
    }
    set
    {
         menmPictureBoxSizeMode = value;
    }
}
 
protected override void Render(IContext objContext,IResponseWriter objWriter,long lngRequestID)
{
    …
        
objWriter.WriteAttributeString(WGAttributes.ImageSize,
            ((int)this.menmPictureBoxSizeMode).ToString());
}

Responsibilities:

  • Maintain the state of the enumerator of the current PictureBox instance.
  • “Render” – write the metadata string to the instructions XML sent to the client when a PictureBox should be rendered on the client side.

DHTML Client Code (XSLT)

<?xmlversion="1.0"encoding="UTF-8" ?>
<xsl:templatematch="WC:Tags.PictureBox"mode="modContent">
    <divstyle="width:100%;height:100%;overflow:hidden;">
      <xsl:iftest="@Attr.Image">
        <xsl:choose>
          <xsl:whentest="@Attr.ImageSize=1">
      <imgsrc="{@Attr.Image}" style="width:100%;height:100%"/>
          </xsl:when>
          <xsl:whentest="@Attr.ImageSize=3">
<tablecellpadding="0"cellspacing="0"
       style="width:100%;height:100%;">
                     <tr>
                           <tdalign="center"valign="middle">
                                  <imgsrc="{@Attr.Image}"/>
                           </td>
                     </tr>
               </table>
          </xsl:when>         
          <xsl:otherwise>
            <imgsrc="{@Attr.Image}" />
          </xsl:otherwise>
        </xsl:choose>
      </xsl:if>
      <xsl:iftest="not(@Attr.Image)">
        &#160;
      </xsl:if>
    </div>
    </xsl:template>…

Responsibilities:

  • Read the attributes from the instructions metadata sent from the server (@Attr).
  • Perform the rendering accordingly; in this case the PictureBox is either rendered as a simple <img> tag or an <img> tag within a table according to the image size mode.

Note: the code above was taken from the client code of the DHTML version of the PictureBox, however, using the same rendered metadata, and any device can render the UI accordingly.

UI Transportation Protocol
The second mechanism which makes it possible to completely decouple the presentation layer form the UI logic is the UI transportation protocol. This protocol is assembled of two different parts:

  1. Metadata behind – which is the XML which is held on the client side and contains the entire layout and controls status as reflected by the last change on the server. This XML represents the persistent state of the client at all times and reflects the exact state of the tree of controls on the server.
     
  2. Events and Commands – which are pieces of pointed data sent from the client to the server and vice versa:
    • Events – to the server when events occur on the client.
    • Commands – back from the server which is instructing the client how to change the metadata behind XML according to the new state on the server.

*This mechanism id described in more details on Command level virtualization.

Conclusion

Due to a clear cut separation of controls code to server and client code and UI transportation protocol, Visual WebGui application is completely agnostic to the presentation device.

Any device that can send and receive XML and render UI is a valid presentation layer of Visual WebGui. The generic communication protocol between the server parts and the client parts makes it possible to implement within each device/presentation technology the rendering part of controls using its own plain and native code and standards.

Next >>