Code Comparison

This demo is available as source in the IntraWeb distribution.

C onsider a very simple demo that contains two forms. The first form allows the user to enter text, and the second form displays it. The second form however keeps a cumulative log of the text passed from the first form, and also allows deletions from the log.

Form Data Demo
(Flash recording - requires flash to view)

To view this in a larger window click here.

Of course this demo is simple, and can be done with plain Webforms. The difference between IntraWeb and Webforms is not what can be done, but how it can be done. The destination is the same, but the journey is very different. Let's take a look at how these applications were built using both IntraWeb and Webforms so we can compare and contrast the differences when building weblications.

First, let's take a look at designing the layout of the first form.

IntraWeb

IntraWeb's custom form designer is very much like building WinForm application forms. Controls can be dropped on the form and placed in any position. Controls also support advanced features such as anchors, and aligns. In this form, the Quit link has been anchored to the bottom and right. When the user resizes the browser, the Quit link will always be in the bottom right corner. The region in the middle is a parent of all the controls on it. It is aligned to center, and will always remain in the center as the user resizes the browser.

Webforms

The Webforms designer supports dragging and dropping of controls as well. However the Webforms designer is more closely bound to the HTML source than is IntraWeb. In the average Webforms application the user must manually edit parts of the HTML source directly to implement certain functionality, or add Javascript. Webforms does not support aligns, so in this case we have had to edit the HTML directly to implement a table to simulate the aligns. There are several problems with this approach however. In this case, tables will only work for the simplest of alignments. Even simple alignments require good knowledge of HTML and manual coding. Advanced alignments are not possible with tables. Editing HTML directly also often causes cross browser incompatibilities as this one has. This alignment works in Internet Explorer, but does not work correctly in Mozilla. IntraWeb not only handles advanced alignments, but automatically compensates for browser, and even browser version differences.

Now let's take a look at the code behind the button click event on the main form.

IntraWeb

In the IntraWeb implementation the Display method of the second form is accessed, and passed the value from the text box. The Display method is a user written method and will be shown later. formDialog is a member variable declared in this form. It is managed automatically by IntraWeb and no other action is needed by the user, aside from initially creating it. Forms can be created dynamically, or they can be persistent. Since this form is reused often it has been declared as a persistent form.

Webforms

Webforms does not support persistent forms. Every page is created on demand, and even between initial rendering of pages and submit handling. This has advantages in lower memory consumption and ability to stream state, but it also causes more processor usage and network traffic. Because of this it often results in slower responses. Because of these different design goals the Webforms handling of the button click is very different. Webforms cannot persist information on forms. Instead all state must either be passed to the next form by encoding it in the URL, or by storing it in simple types in a session object. IntraWeb can merely make a standard method call to pass arguments, Webforms cannot. In this implementation a session object is used to maintain the count of the number of times the second form has been shown,  and the current text so it can be restored on subsequent visits to this form. IntraWeb does this in the second form as we will see later. Webforms must keep all this information separately in the session object where it is not associated with the code that uses it. In this case we are just storing two items, but in bigger applications it is often required to store hundreds of values in the session object which can become quite confusing. You should also notice that each reference into or out of the session object also needs to be typecast or marshaled. IntraWeb allows direct use of types with no conversions.

It must also check to see if the session exists, and if not create one. If already exists, then it can be modified directly. In larger applications the session object is normally initialized elsewhere with a call to a globally accessible method and then later just accessed directly.

After the session object has been updated with the count, and the current text store. Then the next form is shown. This is another key difference between Webforms and IntraWeb. In IntraWeb you can simply use <form class>.show. We will see this later when we look at the user implemented Display method. With Webforms we instead need to redirect to a URL. Since most Webforms applications are deployed into one directory, the filename can be used.

Webforms also must pass all arguments by encoding them on the URL as strings. This limits the type of data, the amount of data, and also provides a breeding ground for bugs. It cannot pass the value of the edit box directly as an argument as IntraWeb can. To pass arguments on a URL, we must list them in the format Name1=Value1&Name2=Value2&Name3=Value3 and so on. The values must also be encoded so that special characters are passed properly. This encoding can be automatically done by calling Server.UrlEncode.

While it may appear simple in this small example, there are several disadvantages to this method.

First, it is a late bound string. If we were to make a typo such as omitting the 'o' and making it FrmDialog.aspx, this error would only be detected at run time when actually executing this code. This is because Webforms "applications" are a collection of independent pages as discussed before. IntraWeb instead uses classes which are resolved upon each compile by the compiler. Any such errors in an IntraWeb application will be detected immediately.

Secondly, the redirect call must be used. We cannot access methods of the FormDialog class directly as we can with IntraWeb.

Now let's take a look at the second form, FormDialog which is shown to the user after the button click. We will start on FormDialog by showing its designers.

IntraWeb

Again a simple form. You can see that the list box has been aligned (docked) to the left.

Webforms

Webforms does not support aligns. The only way in this example to align the list box to the left is to edit the HTML source manually and write custom Javascript for this specific functionality. This requires not only manual editing, but knowledge of Javascript, and becomes very complex when multiple controls become involved.

Let's move on to the code that is executed when FormDialog is shown in response to a button click from the main form.

IntraWeb

This is the Display method that was called earlier. In the Display method is just standard code to use the argument, and update controls on the form. You also notice that there is another variable declared, Count. Count is local to this form and persistent for the life of each instance of this form. In this application only one instance of FormDialog per user is created and has the same lifetime as the users session because it was instantiated as part of the main form as seen earlier. No action is needed upon the developers behalf other than to declare it. Also notice that it is an Int32 and no marshaling or encoding is required. State management is not limited to simple types, classes and complex types can be used as well.

After the visual controls have been updated, the Show method is called. Show is a method of IntraWeb forms and simply specifies that this is the next form to display to the user. As you can see, building an IntraWeb application is almost exactly like building a WinForms application!

Webforms

The handling of the Webforms page is significantly different. Because Webforms does not persist any page information, page information must be recreated on each display, and each submit. When a form submits data back to itself in Webforms, its called a "post back". In this case we can use this to determine if we are being called from an action on this form, or if from another form. If IsPostBack is false, we are being called from the main form. Using the information from the session object we then have marshal the data out and populate the visual controls. In IntraWeb, the list box keeps its data between successive shows, and thus each time we just add to it. Webforms cannot do this, so we must repopulate the list box with the complete history from an array which is stored in the session object.

Between post backs, Webforms does allow for recreation of specified controls automatically. This is controlled by setting a controls viewstate property. This will cause the control to recreate itself as it was shown previously. This however only works for simple controls, and increases bandwidth used.

We must also reparse the arguments passed on the URL. This is done using Request.Params. We then take the value of the "text" field and add it to the historical list in the session.

Finally we must add some Javascript manually to the button attributes. This causes a yes/no dialog to be displayed when the user clicks the button to confirm their action. In IntraWeb, this was set at design time without writing any Javascript by simply setting the Confirmation property to the text value "Are you sure you want to remove the selected item?".

From FormDialog the user has two options. The user can remove selected items from the list box, or return to the main form to enter more text. Let's examine both options in order.

IntraWeb

In IntraWeb the code is the same as it would be in a normal WinForms application. Note that even the ability to show pop up message dialogs is supported. Something else about this form is special that you cannot see from the code, but might notice if you run the demo. This form uses a mode called Partial Update. It is controlled merely by setting the form's UpdateMode property to umPartial in the property inspector. This will cause IntraWeb to send down delta packets instructing the browser to only repaint the affected controls. In this case, when the user clicks the Remove button, only the list box will be repainted in the user's browser. This reduces bandwidth significantly on large forms, eliminates flicker, and eliminates resetting of scroll bars to the top of the page. This feature is only available in IntraWeb. More information on Partial Updates.

Webforms

In Webforms we must remove the item from both the session object and the list box on the form. Webforms also does not support message dialogs, so in this case we have just chosen inaction if no item is selected. To display a message box in Webforms from a server side action requires custom Javascript or addition of a new form.

The other option the user has is to return to the main form.

IntraWeb

Again IntraWeb code is very similar to a WinForms application. In this case we just hide the form by calling the Hide method. This will keep the form in memory for next use. Forms can also be disposed of, but this is a persistent form so we hide it instead. Hiding automatically shows the previously shown form.

Webforms

Webforms does not support any persistence of forms. Instead FormDialog is destroyed and recreated every time it is referenced, even when it is responding to button or link clicks. Because of this, there is no way to simply return to the previously shown form. We must manually specify where to go using a URL.

Webforms

When returning to the main form, no action is need in the IntraWeb implementation. IntraWeb redisplays the form to the user as the user last saw it. However in Webforms the form must be restored manually. View state cannot be used except in cases of post backs, and since this is a new form as far as Webforms is concerned it is not a post back.

This is a simple form, so only one item was stored. However most applications use complex forms that must be manually streamed and reread from a database, or session object.

From the main form, the user can click the button again to add more text to the list box, or the user can click the Quit link.

IntraWeb

WebApplication is a global object in IntraWeb that represents the specific user's application. It can be used to control state, and other aspects about the user's session. It roughly correlates to ASP.net's session object, but implements much more. In this case we call the Terminate method and display a simple message. There are several forms of terminate that also allow displaying of forms, URL's, and other.

Webforms

First we explicitly terminate the users session using Session.Abandon and then display a message. In Webforms there is no method to simply display a message. One option is to create another page and redirect to it. However a simpler option is to write to the Response object directly.

IntraWeb is very similar to WinForms in how it abstracts the GUI API's. In most cases you only interact with the controls in the designer. It is rarely needed to influence the HTML or Javascript directly. If you want to though, IntraWeb allows you. Webforms on the other hand is more closely bound to HTML and Javascript. This means that in an average application you must work directly with HTTP, HTML, CSS, and Javascript. In IntraWeb version of this simple demo the developer needed knowledge of none of these. However in the Webforms version the developer needed advanced knowledge of all three. Specifically:

• HTTP
  • URL management to move between pages
  • Parameter encoding and decoding to pass arguments between pages
• HTML
  • Raw HTML editing to create table to center controls, and simulate anchor of Quit link
  • Raw HTML editing to provide a border for the container of edit, label, and button
• CSS
  • Support for alignments
• JavaScript
  • Used to provide left side docking of list box on FormDialog
  • Used to add a confirmation to the remove button on FormDialog
  • Could be used to implement message box functionality.

This demo was a very simple demo with only two forms, and a very limited amount of state. Because of web applications nature, more forms and more state does not increase complexity linearly, but in a more exponential fashion. Now if IntraWeb makes the simple stuff this much simpler - You can imagine how much easier the tough stuff is with IntraWeb.