Traditional Ajax vs. New Business Targeted Ajax

Introduction

This article compares between the traditional Ajax represented by ASP.NET to that of the new Ajax approach represented by Visual WebGui. The article present an opportunity for developers to learn a way to focus their development efforts on algorithms, requirements and business logics using the new approach to Ajax which provides maximal flexibility, interoperability and interactivity with any traditional web applications, controls set and architectures.

Visual WebGui – is the platform that represents the New Ajax approach suggested by this document.

Download Free Trial

ASP.NET – is referred to, in this document, as a point of comparison, although, any other traditional Ajax development paradigm could be chosen. In other words, this document compares a more generic approach the traditional Ajax development approach with the Visual WebGui’s new generation Ajax approach.

Developer considerations

We will dive into the following developer perspectives:

1. Development languages & environment
2. Required skills
3. Development effort and ease
4. API quality and convenience
5. Ability to use common and proven design patterns
6. Debugging & testing efforts needed
7. Technologies contemporariness

Choosing an infrastructure

In addition, we will highlight some major issues to examine before you go about choosing a platform to base your next line-of-business or data centric application on. The following subjects will be briefly discussed in this document:

1. Infrastructure standards
2. Variety of data controls
3. Binding to data
4. Extensibility/Customizability & look & feel
5. Integration/Interoperability
6. Performance considerations
7. Security factors
8. Scalability

Developer considerations

This section explores some major developer’s considerations when choosing a development platform to base the next project on.

Development Languages & Environment

You will probably choose your development language according to your existing skills and the skills that are most common on your organization.

Visual WebGui developers can choose any .NET language to develop applications with (i.e. C#, VB .NET etc). The Visual WebGui SDK is fully integrated into all of the Visual Studio versions (figure 1).

Visual WebGui adds user interfaces to simplify the application’s configuration (figure 2).

Using ASP.NET without Visual WebGui require manual, xml based configuration (figure 3).

Required Skills

If you have used ASP.NET as well as any other traditional web development paradigms, you already know that any application development task will require additional client side UI/styling languages and concepts: JavaScript & DHTML, CSS, Silverlight, Flex/Flash, Java Applets, and ActiveX etc. (figure 4 and 5).

Fig. 4: ASP.NET MVC Application	Fig. 5: Silverlight MVC Application

Visual WebGui abstracts away from traditional web development complexities and provides single layered .NET server development platform.

Development effort and ease

Plain ASP.NET development provides a generic environment for web sites development, however, when it comes to applications development, and mainly data-centric, line of business ones, the concepts of pages, post-backs, individual HttpXml requests and multi-layered client languages are forcing you to handle more infrastructural questions then application behavior questions.

Visual WebGui offers you to upgrade your data-centric and line of business applications development experience to the level of Forms, Events, Dialogs, Event driven Inter-controls communications and intuitive object oriented behaviors. 

Let’s take a look at a simple task as opening a data bound modal dialog window, a very common task especially for line of business web applications:

Standard web client code

function PopupWindow(url) {
var ie=document.all;
if (ie)
{
        window.showModalDialog(url,”Window”,”status:no; help:no;
                               dialogWidth:1200px; dialogHeight:768px”);
}
else {
      var mywindow =window.open( url, “Popupwindow”,
                             “location=1,status=no,scrollbars=1,width=1200px,
                               height=768px,resizable=1,toolbar=0″ )
                              mywindow.focus();
       }
}

Visual WebGui C# server code

LogonForm objLogonForm = new LogonForm(<…params…>);
objLogonForm.ShowDialog();

Quick review of the codes above:

• In the JavaScript sample, the URL points to a complete context detached URL.
• There is a great deal of work still to be done on client side and maybe even server side in order to send arguments to this dialog and handle them.
• Visual WebGui refers to a completely bound dialog that can accept any number or sort of parameters and can further interact with the other dialogs and controls using plain object oriented and server events.
• Security wise, sending parameters over using client scripting, automatically creates additional client vulnerabilities.

Visual WebGui provides you with the complete power to fully control your applications’ logics, algorithms and data without using multilayered web development languages. All with a single layered object oriented, event driven code and a Form Designer (figure 6).

Graphic-designer-ready tools complement the development process with the ability to easily provide creative look & feel apps (figure 7).

• No CSS documents (although you can still control them)
• No HTML Hell (although you can still customize them)
• No Cross Browsers Incompatibilities 

Download Free Trial 

To be emphasized, although Visual WebGui abstracts away from client scripting and resources, you still have an organized access to those files and you can still override the entire scripting, CSS or HTMLs if needed. So being a web developer can help you provide even better applications (figure 8).

API quality and convenience

Visual WebGui presents a well known API derived from desktop development APIs, however much extending it to the web.

ASP.NET including 3rd party components vendors offer verity of API and most of them are thorough, on the other hand there is no guideline or standard by which you always know how to interface with those controls and you can never know if you will be able to accomplish future tasks using common controls.

With Visual WebGui, not only you have a large set of controls, all fully featured and with AJAX native behavior, you can always easily extend those controls or customize them according to your needs.

Visual WebGui API is event driven; this means that your entire development will concentrate on handling events and performing the application logics.

For example, let’s explore the simple task of handling a click event of a tree node located on the left hand of the application and filling up a list located on the right hand:

Standard Ajax approach:

• Locate the right way to handle the client event of clicking a tree-node.
• Make sure that you know how to read the required data from the selected tree-node.
• Option 1
  • Send the values over to the server using free style HttpXml or ASP.NET AJAX
• Option 2
  • Locate the way to affect the list control’s mechanism and force it to perform server update call with parameters
• Grab the values on the server side and retrieve whatever data required to fill the list
• Send back the data or an inner HTML form to the client.
• Capture the callback on the client side with the data from the server
• Perform the local update of the list as needed

Visual WebGui new Ajax Approach:

• Attach the AfterSelect event of the tree view.
• Write event handler code to retrieve the data and at the same time fill it into the list using plain C# (as shown below).

private void treeView1_AfterSelect(object s,TreeViewEventArgs e)
{
   //Populate ListView 
   while (objDataReader.Read())
   {
      for (int i = 0; i < objDataReader.FieldCount; i++)
      {
         ListViewItem objItem = new ListViewItem();
         objItem.Text = objDataReader.GetName(i).ToString();
         objItem.SubItems.Add(objDataReader[i].ToString());
         listView1.Items.Add(objItem);
      }
  }
}

* The entire action will be performed once on the server and
then reflected back to the client at runtime.

Quick review of the codes above:

• Inefficiently long development process as opposed to a well defined events API usage.
• Imagine having more than one control to update as a result of the tree-node click event; then you would have to perform 2 requests/response roundtrips. It’s easy to discover that Visual WebGui is also much more efficient at runtime since it goes back to the server once with no further client processing, then returns back once and updates the whole UI changes in this one roundtrip and with no post-backs.  

Ability to use common and proven design patterns

Web architecture separates almost completely between the client and the server creating a decoupled architecture on which the developer should find ways to bridge and cover.

It is most common that well defined design patterns are much more complex to achieve on top of the traditional web architecture; for example:

• Data Validations: What kinds of validations should exist on the client side and what validations should be tested on the server? Maybe both?
• MVC: Where do we actually split between the client side’s role and the server side role? In addition, in case we have got some logics on the client side, does this mean that we should also have parts of the controllers’ mechanism on the client?(figure 9, 10)

Fig. 9: Server based MVC	Fig. 10: Mixed client/server MVC

• Observer/Command: Which kinds of events should be raised to the server in order to bubble the events between the listeners?
• Service locator: Where should we keep the service locator code? On the client side on the server side? Maybe both?

A single layered development environment, were you write your entire code at a single coding language and handle it as an optimized event driven infrastructure on top of a complex, multilayered  environment will make your life much easier in trying to apply quality design patterns.

Debugging & testing efforts needed

Traditional web debugging requires:

• Server code debugging (using Visual Studio)
• Client-server communications debugging (figures 12-13 using Visual Studio and client development tools)
• Client scripting language debugging (figures 12-14 using client development tools)
• HTML and CSS actual rendering (figure 14 using client development tools)

Visual WebGui debugging means debugging an object oriented C# code only (figure 15)

Technologies contemporariness  

Assuming you are done with the development process, ending up with the work-of-art application on top of the traditional web development paradigms then your customers are pretty much locked into consuming the app. through DHTML browsers.

In addition, developing DHTML 4 and certain CSS standards means you will need to invest an additional large amount of time in order to upgrade your application to newer standards.

With Visual WebGui, you can use any .NET version (currently 2.0 or 3.5) on the server, while the client is completely agnostic. Visual WebGui provides alternatives for any standard DHTML clients with no installation supporting any browser as well as Silverlight enriched browsers with no additional development effort.

Visual WebGui will continue to maintain the contemporariness of both server and client technologies keeping you updated with the cutting edge technologies at all times and with minimal to non effort (figure 16).

Choosing an infrastructure

The following short explanation summarizes the major considerations of choosing an application development infrastructure that will ensure the customer’s satisfaction and the quality of the product.

Infrastructure standards

In order to fit most of the customers’ current infrastructures, we should make sure that we base our solution on a well known existing and proven infrastructures.

Visual WebGui is based on ASP.NET the deployment using XCOPY simple deployment.

Visual WebGui communication layer is based on plain XMLs over HTTP and supports any plain web browser Silverlight or any device with no specific installation!

Variety of data controls

In order to make sure that you are able to deliver any sort of UI needs and any common way possible way of presenting/updating and interacting within the application and more specifically its data, you will probably want to examine the out-of-the-box verity of data controls.

Visual WebGui contains a set of above 50 controls out-of-the-box and a set of complementing libraries with about 20 more additional controls, supplying you the complete suite for any common interaction and manipulate (figure 17).

In case you need more, you can either import in any ASP.NET based 3rd party control, create your own or customize one of the existing once (see Extensibility/Customizability & look & feel). 

Binding to data

Complete Data-binding options make it easy to concentrate on the business logics of the application as opposed to struggling with various techniques for binding your UI to data (figure 18).

Extensibility/Customizability & look & feel

Visual WebGui’s extensibility & customization options are served as productive driven tools to the developer. The mechanisms required to apply design changes and runtime abilities are wrapped into an optimized engine (figure 19).

Except for the WYSIWYG forms designer, Visual WebGui provides a visually simple solution to edit, re-create and customize Visual WebGui controls. In addition, an automatic tool for migration of 3rd party controls is also enabled immediately widening the available verity of controls with all the kinds of ASP.NET based controls by any of the existing providers.

As for branding and UI customizations, you have the complete power to customize & brand the application using a point & click designer to change the look & feel completely according to the customers’ requirements.

Integration/Interoperability

Based on a generic desktop compliant API and enjoying the fact that its ASP.NET based web under the hoods, Visual WebGui offers a very wide solution. Starting from stand alone applications development through mash-ups and ending-up in highly interactive and data centric add-ons.

Visual WebGui offers the ASP.NET FormBox control which enables ASP.NET based applications to contain Visual WebGui applications. Figure 20 show a large testing central application by SAP (called SNAP), which combines Visual WebGui with ASP.NET.  The data centric and interactive part in the middle is Visual WebGui and the surrounding “frame” is ASP.NET.

The opposite option is a Visual WebGui application being able to contain an ASP.NET application. This option is provided in the form of a control named AspPageBox in Visual WebGui (Figure 21).

Performance considerations

Although Visual WebGui is a server centric architecture it optimizes the communication and the balance between client and server responsibilities and provides low latency and excellent performance. In highlights level, the following factors are producing this outcome:

• Low CPU usage on the server side low negotiation establishment time due to the existence of valid context at all times.
• Highly optimized communication protocol based on compressed deltas metadata and minimal commands.
• Leveraging the client machine power to minimize communication and throughput.

The effectiveness of the protocol is shown in the following graphs (figures 22-23) based on external testing performed by a performance specialist Microsoft MVP Mr. Wiktor Zychlah.

 

Security factors

Visual WebGui Empty and static client with no ability to change logics is the preferred approach for enterprise business applications data security.

It is not that traditional web paradigms are not securable; however, the effort that is required to support such information safety level is significantly bigger.

In addition, encryptions/decryptions and obfuscations at runtime are costly and might affect performance so it is highly preferred avoiding them by-design.

Scalability

Due to the unique optimizations of the state memory and persistence model (memory serialization), Visual WebGui based solutions are fully scalable using a floating session and the average penalty for having a centralized persistent state is ~15ms per call. A schematic diagram is shown in figure 24. This fact makes Visual WebGui is an optimized solution for cloud computing architecture as well as on-premise or standard hosting deployments.

Download Free Trial