Nevron .NET Vision
Framework / Thin Web / Thin Web Overview
In This Topic
    Thin Web Overview
    In This Topic

    The ThinWeb controls in the package (Nevron Chart and Diagram ThinWeb) aim to provide a consistent way to create AJAX enabled charts, diagrams, maps and gauges across variable .NET framework web server technologies such as ASP.NET WebForms, MVC, MVC Razor and Sharepoint. Both controls use the JQuery library in the client which results in cross browser compatible client script that is tested with all the current major browsers including IE, Firefox, Google Chrome, Opera and Safari.

    Both controls follow the MVC design pattern and their API is similar to the code you use in Windows Forms applications. This allows you to easily test and port code created for the desktop to the web world.

    The following sections provide a brief overview of the ThinWeb architecture that is common to the Chart/Diagram ThinWeb controls.

    HTML Page Service Models

    The traditional html page service model is very simple - the client browser sends a request and the server responds with a HTML page:

    Since HTML however can contain links to data accessible from different URLs (like image, iframe, script etc.) the actual HTML page service model is as follows:

     

    Note the the request / response marked in red on the above image are actually implied by the generated HTML and are not initiated by the user. In the ThinWeb controls we've tried to minimize the amount of such implied requests which leads to greatly improved performance compared to other AJAX controls.

    The traditional service this model however it is not well suited for pages that need to update frequently as this results in lots of traffic between the client and server. This is why the traditional model has been extended to the AJAX model:

    Note how the AJAX processing model adds two additional stages in the page lifetime that are generally executed asynchronously. The update request and response data format depend on the application and developer preferences (HTML, JSON, plain text, Binary etc.), however no matter how complex the website is, the general processing model is unchanged.

    Adding these two aditional steps to the service model of HTML pages complicates the model, because in order to service an update request the server must know which page it is currently updating. In different web server frameworks this is commonly achieved trough either sending chunks of data in the update request that contain the page current state (like in the Postback processing model) or rely on the server session state. The ThinWeb controls rely solely on session state, because this results in less traffic between the client and the server.

    ThinWeb Server Architecture

    The ThinWeb control has the following properties;

    Document - this property gives you access to the current state of the document that is processed by the control. The document is persisted in the session state of the server and is identified by the StateId property. The StateId remains constant across round trips whereas the Document changes in response to user actions or server side code.

    Controller - this property gives you access to the Tools collection holding the different tools that control how the client side events are processed.

    ServerSettings - this property holds settings relevant to the type of response send by the server as well as how the document is converted to HTML - for example whether to use tiled images, the size of the each tile image chunk etc.

    This is illustrated by the following picture:

    The Document, Controller and ServerSettings objects are persisted in the session state.

    The processing of a page containing the ThinWeb control follows the AJAX processing model:

    Initially the page generates the HTML and Script content and subsequent updates of the controls will modify only the Toolbar and View div blocks content and the rest of the page will not be changed. This processing model has several entry points that correspond to the to the type of request the server is currently processing:

    - Script rendering (executed when the page is rendered for the first time)

    - Initial Content rendering (executed to generate the initial HTML of the control)

    - Service (update) request rendering (executed when processing client update requests).

    Depending on the server side you use these entry points are exposed as follows:

    ASP.NET Web Forms

    - Script rendering

    Script rendering is performed in the OnPreRender override of the ThinWeb control and is generally hidden from the developer.

     - Initial Content rendering

    The initial content rendering is performed in RenderControl control override.

    - Service request rendering

    This entry point is exposed by several .axd handlers.

    MVC

    In MVC applications you need to create a small controller class that exposes these entry points to the framework. The MVC integration examples show how to achieve this. 

    In both frameworks the ThinWeb control Initialized property is set to true if the control is currently processing an update request. The following code snipped show how this is usually handled in server side code:

    C#
    Copy Code

    if (!someThinWebControl.Initialized)

    {

    // perform initialization here

    }

    Visual Basic
    Copy Code

    If (Not someThinWebControl.Initialized) Then

    ' perform initialization here

    End If