Client, server and Ajax events - WebUI Studio |
Written by Ian Elliot | ||||||||||||||||||||||
Tuesday, 04 January 2011 | ||||||||||||||||||||||
Page 2 of 3
Client side controlA progress bar sounds like a simple idea but notice that it has to communicate with some other process to show how something is progressing. It is often a server process, e.g. saving or loading a file, but it could also be a client side process, a long calculation say. Clearly the "difficult" part of dealing with a progress bar is implementing the mechanism that causes it to update. Let's start as simply as possible. In Indeterminate mode the progress bar simply runs an animation of the "slider" moving up and down the bar. The animation is controlled by the Interval property which give the number of milliseconds between each animation step. In Indeterminate mode this is the only functional property we have to set. Make sure that you have set Interval to 100 and Mode to Indeterminate. To make things as simple as possible we will control the ProgressBar using just two buttons. Place two WebButtons on the form and set the first's Text property to Start and the second's to Stop. The key idea here is that of Client Side Events. All of the Intersoft ASP .NET components support not only the usual Server Side Events that make ASP so different to every other approach to building web apps but they also support Client Side Events. A Server Side Event generally causes a round trip to occur with the event data sent back to the page at the server. In this case the event handler is usually written in C# (or VB) and is contained in the code behind for the web page. Any changes due to the event handler are rendered as HTML and the whole lot sent back to the client. A Client Side Event is what it sounds like. The event is generated in the client browser and handled within the browser. The most usual way of doing this is to write a JavaScript event handler. At this point you might want to point out that client side events are the norm for non-ASP.NET web applications. This is indeed true but they are not usually part of an ASP.NET application and the Intersoft controls provide an easy and consistent way of mixing the usual ASP .NET server side approach with client side events. It's very clever and very simple. Now let's see it in action. The WebButton has two Client Side event properties - OnClientClick and OnClientInitalize - that you can use to specify the names of JavaScript functions that will handle the appropriate events. In this case we only need the OnClientClick event and this property should be set to ProgressStart for the first button and to ProgressStop for the second button. Now we have to write these two JavaScript functions. To do this the simplest approach is to switch to Source mode in the editor and directly enter the <Script> tags and JavaScript. This is easy but how do we make the connection with the ProgressBar object - after all this is an ASP .NET server side control not a JavaScript object? The answer is that there is an ISGetObject untily function that will retrieve the JavaScript API of any InterSoft control. In this case we need to retrieve the API by the control's name e.g.: var progBar = ISGetObject('ProgressBar1'); Once you have the JavaScript object corresponding to the controls client side API you can call method and set properties in the usual way. Each control supports a different client side API and the ProgressBar supports:
So to start the animation off all we need to do is call DoStep and to stop it we call Finish - notice that there is no need to call Start although for reasons to be explained this is usual. With this information we can now write the JavaScript to start and stop the ProgressBar: <head runat="server"> If you now run the web page you will see the progress Bar animate when you click the Start button and stop when you click the Stop button. Notice that all of this is controlled by the client side code - no round trip or server processing is involved.
At this point you might be wondering what the Start method is for - after all you don't need it to start the animation off as DoStep does that. The answer is that the Start and Stop methods trigger events that signal the state of the ProgressBar to other interested parties. What is really interesting is that there is a client side event and a server side event corresponding to the ProgressBar Finish. That is you can choose to handle the event locally within the browser using JavaScript or you can perform a postback to let the server reconfigure the page in response to the event. This is flexible but once again we have the basic problem of the cost of a full round trip postback. The obvious solution is to use an Ajax-like method and Intersoft components have a really clever and very versatile approach to Ajax-style postbacks called FlyPostBack which provides a server side handling mechanism that doesn't involve a full postback and is much more flexible. Let's look in more detail at the three ways of handling events.
<ASIN:1430225114> <ASIN:0672331128> <ASIN:1453895078> |
||||||||||||||||||||||
Last Updated ( Wednesday, 02 February 2011 ) |