AJAX

JS Intellisense in Orcas

Joel Rumerman — Sat, 03 Mar 2007 17:43:00 GMT

It’s finally here!!

JavaScript intellisense is available in the March 2007 CTP of Orcas (the next Visual Studio). It works well with plain old JavaScript, but it really shines with ASP.NET AJAX.

Jeff King does a good job of documenting the new capabilities in this blog entry.

For us ASP.NET Server Control developers that utilize client capabilities, this is a huge boon for us. When was the last time JS intellisense was updated?? Anybody? I have no idea… I don’t think it’s changed since the first release of Visual Studio. Having to program ASP.NET AJAX client runtimes with intellisense … AWESOME!!!

Also, I mentioned an excellent article in my webcast that describes the prototype/closure model. I finally found it… here it is.

IMHO, it’s the single best article that describes closures available.

ASP.NET AJAX Client Component Development WebCast

Joel Rumerman — Thu, 01 Mar 2007 12:08:00 GMT

Hello Everyone,

Thanks so much for attending today’s webcast! We had 150+ attend and this is just a testament to how important and interesting a subject MS ASP.NET AJAX is.

As promised, here is the source code from today’s webcast. This is free source code, no limits on modifications, re-use, redeployment to clients, etc. I don’t even have my name in it yet.

I will add however, that the component that is supplied in this source code only works in certain situations. Try sticking a button you want to disable within an UpdatePanel and see what happens. It’ll work the first time, but in subsequent partial postbacks. There’s another, longer version of the source code that I’m working on that is more fully-baked that can be reused successfully across web applications and in different scenarios.

Again, thanks for joining me today on the webcast. I hope you enjoyed it and learned something interesting! Stay tuned for more webcasts regarding ASP.NET AJAX custom development. I think I’m going to put a couple of more in the pipeline.

Download Source

February SD .NET Developers Group Talk on ASP.NET AJAX Component Creation

Joel Rumerman — Wed, 07 Feb 2007 16:01:00 GMT

Thanks to everyone that attended the meeting and heard my talk about ASP.NET AJAX Component Development. We had a great time hosting and I hope it sparked some interest in ASP.NET AJAX Component development and that you were able to learn something new.

Here are the slides and code from my presentation. I’m not attaching the postback disabler control at the moment (the last thing I demoed at the meeting) as it’s not ready to go yet and I think I’ll blog more in-depth about it in the next few weeks.

Happy coding, and thanks for attending!!

File Attachment: ASP.NET AJAX Component Development.ppt (745 KB)

File Attachment: DemoAJAXWebsite.zip (22 KB)

Web Development Helper Release

Joel Rumerman — Tue, 14 Nov 2006 11:23:00 GMT

Nikhil has just released a new version of his irreplacable Web Development Helper tool. If you’ve been coding in ASP.NET AJAX (Atlas) or in another AJAX way that submits XMLHttp requests and haven't been using this tool you've been missing out on a great tool that really helps with debugging and troubleshooting asynchrounous requests.

He’s added a bunch of new features to check out including: JSON viewers, a new viewer for partial rendering scenarios (focusing on the ASP.NET AJAX UpdatePanel), and an installer that solves some of the earlier headaches and that is Vista compliant.

Check out his blog post about the release here. And download it from his project page here.

The UserContext Property of Atlas Web Service Alternative Syntax

Joel Rumerman — Fri, 22 Sep 2006 10:58:00 GMT

Atlas enabled web services are fantastic. They provide a rich, wrapped capability that abstracts a lot of the nitty gritty xmlHttp details away from the programmer.

The normal pattern of using Atlas Web Services is a static method call that contains a callBack delegate. Once the method is complete, the callback function is automatically executed. For the most part, the code looks like the following:

    function startWebService() {
        AtlasWebService.Geography.GetCities (CountryId, onCallback, onTimeout);
    }
    
    function onCallBack (results) {
        // do something with the results.
    }
    
    function onTimeout (results) { 
        alert (“call Timed out”); 
    }

Here I'm executing the GetCities web service method passing in the CountryId as the parameter and registering the onCallback method as the onMethodComplete handler and the onTimeout method as the onMethodTimeout handler.

For simple situations this works great, but in a project a while back we needed to pass some context from the caller (startWebService) to the callback (onCallBack). Using the version of the web service calling pattern that I've demonstrated above, this isn’t possible. A thought we had to solve this problem was to wrap the function calls inside of a closure and use private members of the closure to hold state. Something like this:

    myClass = function () {
        _currCountryId= '';
        this.startWebService = function (CountryId) {
            _currCountryId= CountryId
            AtlasWebService.Geography.GetCities(_currCountryId, onCallback, onTimeout);
        }
        
        function onCallback (results) {
            alert (_currCountryId);
            // handle the results as needed.
        }
    }

While this looks like it might work from initial glance (besides the race condition that might be present if more than one call to startWebService occurred before the first one completed), we found that _currCountryId wouldn’t be available to the onCallback function. Without jumping into too much JavaScript, the onCallback call is private and therefore unable to access the closure’s member fields (I think that’s the reason at least). Changing the onCallback method to “this.onCallback = function (results)” didn’t work either.

It turns out we were thinking too hard and not reading enough documentation. Atlas’ web service pattern provides a pass-through capability out of the box by using the alternative syntax and the userContext property. The Atlas documentation’s alternative syntax can be found here and the example reads:

    requestSimpleService = Quickstart.Samples.SimpleService.EchoString( 
        document.getElementById('inputName').value ,  // First webservice parameter     
        secondParameter,                             // Second webservice parameter 
        { 
	  onMethodComplete:OnComplete, 
	  onMethodTimeout:OnTimeout, 
	  onMethodError:OnError,
         onMethodAborted:OnAborted, 
	  userContext: "OnbuttonGo_click", 
	  timeoutInterval: 10000
	} 
    );
The blurb below it reads: “The userContext parameter can contain any value (string, number, array, dictionary, or object) and is used to pass contextual information that can be retrieved inside of handlers for errors or time-outs.”

In this example they are passing “OnbuttonGo_click” as the user context. They state the “contextual information that can be retrieved inside of handlers for errors or time-outs,” but it can also be used in the normal callback handler and anything that can be successfully serialized into JSON can be passed.

Let’s take a look at our example using the alternative syntax.

    function startWebService(CountryId) {
        AtlasWebService.Geography.GetCities (CountryId,
            {
                onMethodComplete: onCallBack,
                onMethodTimeout: onTimeout,
                userContext:CountryId

            }
        );
    }
    
    function onCallBack (results, response, userContext) {
        alert (userContext); // will popup the countryId of before.
    }
    
    function onTimeout (results, response, userContext) {
        alert (“call Timed out for: ” + userContext);
    }

Now, when the web service method returns, the onCallBack function will have both the results as well as the userContext I assigned to the method call in startWebService method.

A couple of things to note:

I didn’t include the full alternative call syntax. Since it’s a named parameterized list of properties, it isn’t required that all of them be included.
The onCallBack method signature now has 3 parameters. Results, response, and userContext.

By using the userContext property of the alternative syntax I can pass extra data from my caller to my callback. This is pretty darn helpful.

Happy Coding, Joel

Atlas - June CTP

Joel Rumerman — Sat, 01 Jul 2006 12:24:00 GMT

Microsoft has released the June CTP of Atlas. You can download it here.

Nikhilk has posted a blog entry describing the core new feature of the CTP; Dynamic UpdatePanels. This is by far the biggest new feature of the CTP (and the last 6 months) and provides a completely new pattern of development for server controls and websites in general that want to take advantage of partial postbacks. I’m totally stoked about this new feature as I’m sure all other Atlas developers are, and want to thank Eilon and the rest of the Atlas team for listening to the early adopters cries and responding. I’m sure there are going to be pitfalls and areas where the new Dynamic UpdatePanel still doesn’t do exactly what I need it to do, but it’s a step in the right direction. I’ll play around with it in the next few weeks and post an entry or two sharing any insights I glean. I just wish that we weren’t so far along in our real Atlas project that taking advantage of it at this point is probably going to cost too much.

Other than the Dynamic UpdatePanels, one feature that I’m really going to like is the ability to see the generated JS code for a service proxy within the page that contains the service proxy. This has been a problem for us as we tried to debug the web services contained within the ScriptManager and I’m excited to have this new ability.

One thing I’m a little disappointed in is that there is no new documentation in the docs section of the Atlas site. Just from reading Nikhilk’s blog entry there seems to be a lot of new server side classes that we’ll need to understand in order to take advantage of the new features. I’m sure that some client side code has changed too. I’m not too sure if MSFT plans on updating the docs for this CTP, but it sure would be nice.

Emitting JavaScript to run on Startup in an Atlas Environment

Joel Rumerman — Tue, 20 Jun 2006 16:40:00 GMT

I’ve been working with Atlas since the December CTP and in the past few weeks I’ve grown to really appreciate the way that it formalizes JavaScript programming and the framework it provides for extension. Creating client side behavior for server side controls is repeatable, flexible, and just an overall better experience.

However, there is one particular problem that is currently drawing my ire and it relates to how Atlas dependent JavaScript needs to be emitted to the client so that it executes correctly on startup, both from a normal page load point of view and a partial postback point of view.

In a non-Atlas environment I use the Page.ClientScriptManager.RegisterStartupScript function to register any startup JavaScript. However, if I were to register some JavaScript code that relies upon Atlas, for instance var myLabel = new Sys.UI.Label($(‘ctrl1_lblName’));, using the normal RegisterStartupScript functionality, the browser would throw a JavaScript error as it doesn’t know what Sys.UI.Label is and it is unable to create a new object of that type. This error makes sense as there is no guarantee that the Atlas JavaScript files will be loaded by the time your startup code is executed as your startup JavaScript code is executed immediately after it is parsed by the browser. Having said that, Atlas provides a way to tie into its Application Load event, which is sort-of the equivalent of the body onload event, but occurs once all of the Atlas JavaScript files have been loaded and the Atlas runtime has been started. The way to do this is wrap your startup code in a function and then register that function as a delegate of the Application Load event. Here’s a code example.

Normal startup code …

var myLabel = new Sys.UI.Label ($(‘ctrl1_lblName’));
myLabel.initialize();

Startup code wrapped in a function and registered with the Application Load event.

function myStartupFunction () {
var myLabel = new Sys.UI.Label ($(‘ctrl1_lblName’));
myLabel.initialize();
}
Sys.Application.load.add (myStartupFunction); // notice how myStartupFunction doesn’t have parentheses; it’s a delegate (function pointer).

This above code would be registered using the RegisterStartupScript method. Now, when the page first loads and Atlas’ runtime begins, myStartupFunction is part of the load multicast event and is executed in the order it was added to the event. This process can be repeated again and again as necessary for any startup code that relies upon Atlas.

This pattern works for JavaScript that is loaded on the initial page load or on a full page postback, but there exists a problem when using this pattern with UpdatePanels and performing a partial postback. The functionality of an UpdatePanel provides a way to render a section of a page without the user thinking a full postback is occurring. If a control or a page emits the JavaScript above and the developer wishes to have the JavaScript execute even on a partial postback page load, the above pattern won’t work because the Sys.Application.load event only fires the first time the page is loaded. It is not fired on subsequent partial loads. Currently (as of the April CTP), there is no event that fires as a load event that encompasses both the initial loading and a partial postback load. However, there is a work around and so far it is has proven reliable.

The work around relies upon the server code determining if it is partial rendering mode or not. Partial rendering mode can be determined by examining a property on the ScriptManager control, IsInPartialRenderingMode, that denotes whether the page got to the server through a partial postback, through a full postback, or through an initial page load. If it the server code is executing due to a partial postback, IsInPartialRenderingMode will be set to true, otherwise it will be set to false. If IsInPartialRenderingMode is set to false then the above code where we tie into the Sys.Application.load event is the route we want our code to take. If IsInPartialRenderingMode is set to true, we want to follow a different, very simple pattern of just registering the function as normal startup JavaScript. Here’s a code example.

// in some server side method like OnPreRender

…

String javaScriptFunction = @“
function myStartupFunction () {
var myLabel = new Sys.UI.Label ($(‘ctrl1_lblName’));
myLabel.initialize();
}”

// this could should have error checking for nulls.
Page.ClientScriptManager.RegisterStartupScript (javaScriptFunction);

ScriptManager myScriptManager = ScriptManager.GetCurrent(Page);
if (myScriptManager.IsInPartialRenderingMode)
{

Page.ClientScriptManager.RegisterStartupScript (“myStartupFunction();”);
}
else
{
Page.ClientScriptManager.RegisterStartupScript (“Sys.Application.load.add (myStartupFunction);”);

}

In the above code where it tests myScriptManager.IsInPartialRenderingMode the code branches to either use the Sys.Application.load event or just emitting the function execution directly on the page. Emitting the function directly to the page (using RegisterStartupScript, which is a must!!) causes the code to be executed on parse. This time through the code won’t throw an exception as all of the Atlas JavaScript files have been loaded and the Atlas Runtime has been started.

So, there you have it. A way of executing JavaScript code that relies upon Atlas on both an initial load and a partial postback.

Atlas: Page Lifecycle for Partial Postbacks

Joel Rumerman — Sun, 23 Apr 2006 18:58:00 GMT

A piece of information that I’ve tended to gloss over until now was that during a partial postback by means of an Atlas UpdatePanel, the server life cycle goes through a normal postback life cycle. I never gave this much thought until I was considering what this meant for performance. Were all of my controls re-rendering even if they weren’t contained within an UpdatePanel that was set to update? How did the server side Atlas framework know to only send the HTML for the controls that were contained in an updating UpdatePanel down stream? Was there a way to make my code perform better knowing that I was working within the Atlas framework?

The simple answers: Yes. The framework is smart. I’m not too sure.

The more complete answers ….

All controls are participating in the postback in normal life cycle fashion. Their viewstate is loaded; their controls created; their data, bound. The major difference occurred when it came to any of the render methods (BeginRender, Render, EndRender, AddAttributesToRender, etc.) that normally had an HtmlWriter parameter. Here, in one of the previously stated methods (e.g. Render) an updating UpdatePanel used a normal HtmlWriter parameter as expected. However, in the same method within a control that wasn’t within an updating UpdatePanel, the parameter was of type Microsoft.Web.UI.DummyHtmlTextWriter. Whoa … what this means is that there are two HtmlWriters. Whether you are going to be re-rendered down to the browser or not determines which HtmlWriter is used. (BTW, thank Microsoft for creating the DummyHtmlWriter type. I’m pretty sure that they could have used a NullTextWriter when they didn’t want a control’s output to be sent to the browser, but if nothing else, the DummyHtmlWriter makes it really clear that this control isn’t actually going to be sent to the browser.)

The next logical question I had was why Microsoft didn’t program it so that if a control wasn’t going to be re-rendered and sent down to the browser it never entered the Render phase and therefore eliminating the need for the new DummyHtmlWriter type? The answer actually came from Microsoft because I was stuck on this one for a while. The reason for this was because the EventValidation hashcode is created in the Render method and when a page has EventValidation enabled (as all pages do normally and it’s the default) the base Render method must execute at the appropriate time in order for this hashcode to be created. (As a side bar, to understand the Event Validation, see K Scott Allen's Blog Entry on Event Validation or Shawn Burke's Blog Entry on the Cascading Dropdown Control, but it pretty much prevents unauthorized postback values.) Therefore, in order for a page’s EventValidation hashcode to be correct, all of its child controls must execute their render methods to create their hashcodes which can be passed up the chain and hence the reason that all controls must be re-rendered.

Up until now, I’ve answered my first two questions, but is there a way, knowing I’m working within the Atlas Framework, to program slightly differently to make my code run faster? Truth-be-told, I don’t see too much. There’s a basic knowledge of knowing that I’m in a postback and therefore loading or not loading data as appropriate, but other than that I’m not sure.

A question remains … I have a drop down with the values 1, 2, 3. They are rendered initially, but not re-rendered on a postback. An UpatePanel causes a partial postback (does not contain the dropdown). Will I get an EventValidation exception if I perform a normal full postback? So normally if I perform a postback I would have to re-render the dropdown either from ViewState or from my initial data in order for the dropdown to display. But, if I perform a partial postback my dropdown values will still exist on the page because I’m not replacing the Html associated to that area of the page. But the page’s EventValidation hashcode won’t contain the dropdown’s values because they were never re-rendered. What happens when I perform a normal postback?? I’ve been sitting in front of my computer on an awesome Sunday for way too long to test this right now, but I’ll post a follow up soon.

Atlas: Creating a clientside bindable business object

Joel Rumerman — Wed, 29 Mar 2006 22:55:00 GMT

I’ve recently come across a situation in an application I’m working on where I’d like to bind a client side business object that is defined by a JSON statement to a series of labels. Out of the box, Atlas provides a way to bind one attribute of a component to an attribute of another component by defining a Sys.Binding object in JavaScript or a <binding> tag in xml-script and adding it to a component’s binding collection. For example, I can bind the text of a label to the text of a textbox or the cssClass of a button to a drop down list’s selected value. There's also a way to bind a list of items to a ListView or other list type object using an Atlas Datasource, but it only works with DataTables and Arrays. (There are complete code examples in the Controls and UI Quickstart on the Atlas site.) However, my business object isn’t a Component, it’s just a server side state bag (entity object, domain object, whatever) that’s been serialized into JSON format so the browser can access it. So how do I make it participate in binding?

In my research I realized that to accomplish something like this, the client side business object must be a Component itself as components can be bound to other components. (A good explanation of how binding works in Atlas can be found at Wilco Bauwer’s Blog about 1/2 way down.) So I went about the path of creating a business object that derives from Sys.Component so it can participate in bindings.

(BTW, binding comes in handy when you can't use an UpdatePanel to refresh a control’s values such as when you're doing custom control development and you’re well past the InitComplete event when the control is added to the page.)

So, following the pattern defined by other bindable controls in the Atlas framework such as the label and textbox, I created a client-side object that inherits from Sys.Component. Inheriting from Sys.Component provides my business object with the capabilities to raise propertyChanged events and participate in bindings. (Actually, the INotifyPropertyChanged interface implemented by Sys.Component provides the propertyChanged ability.)

On to the code …

            // create some private variables.
            var _createDate;
            var _description;
            var _name;

            // initialize function
            this.initialize = function() {
                BindableKeyword.callBaseMethod(this, 'initialize');
            }

            // create date getter
            this.get_createDate = function()
            {
                return _createDate;
            }

            // create date setter
            this.set_createDate = function (value)
            {
                // if the current createdate value != the new value
                if (_createDate != value) {

                    // update the createDate's value
                    _createDate = value;

                    // raise the propertyChanged event
                    this.raisePropertyChanged('createDate');
                }
            }

            // description getter
            this.get_description = function ()
            {
                return _description;
            }

            // description setter
            this.set_description = function (value)
            {
                if (_description != value)
                {
                    _description = value;
                    this.raisePropertyChanged('description');
                }
            }

            // name getter
            this.get_name = function ()
            {
                return _name;
            }

            // name setter
            this.set_name = function (value)
            {
                if (_name != value)
                {
                    _name = value;
                    this.raisePropertyChanged('name');
                }
            }

            // override the getDescriptor of the base class.
            // This is where we define the bindable properties.
            this.getDescriptor = function() {

                // execute the base class's getDescriptor to get the TypeDescription
                var td = BindableKeyword.callBaseMethod(this, 'getDescriptor');

                // add the name property
                td.addProperty('name', String);

                // add the description property
                td.addProperty('description', String);

                // add the createDate property
                td.addProperty('createDate', String);
                return td;
            }

            // register the override.
            BindableKeyword.registerBaseMethod(this, 'getDescriptor');
        } // end keyword class

        // Set the BindableKeyword's base class to Sys.Component. This is important as Sys.Component provides the framework
        // for binding to take place.
        BindableKeyword.registerClass('BindableKeyword', Sys.Component);
        Sys.TypeDescriptor.addType('script', 'BindableKeyword', BindableKeyword);

// Some test code to play with my new BindableKeyword object.

        // create a new BindableKeyword.
        var bindableKeyword = new BindableKeyword();

        // set the name
        bindableKeyword.set_name ("Test Name 1");

        // Create an Atlas label that refers to one of the spans I declared in the HTML.
        var lblName = new Sys.UI.Label($('lblName'));

        // Create the binding on the label
        var binding_1 = new Sys.Binding();

        // set the dataContext (really the dataSource) to be the BindableKeyword
        binding_1.set_dataContext(bindableKeyword);

        // set the property path within the BindableKeyword to bind to.
        binding_1.set_dataPath('name');

        // set the property within the label to update with the data from the BindableKeyword
        binding_1.set_property('text');

        // setup the binding direction.
        binding_1.set_direction(Sys.BindingDirection.In);

        // Add the binding to the label
        lblName.get_bindings().add(binding_1);

        // Initialize the label
        lblName.initialize();

        bindableKeyword.set_name ("Test Name 2");
        alert ("pause");
        bindableKeyword.set_name ("After Set Name 3");
     }
    </script>

</head>
<body>
    <form id="form1" runat="server">
        <atlas:ScriptManager ID="sc1" runat="server"></atlas:ScriptManager>
        <div>
            <span id="lblName">Unbound Name</span> <span id="lblCreateDate">Unbound Create Date</span>
            <span id="lblDescription">Unbound Description</span>
        </div>
    </form>
</body>
</html>

Basically what I’m doing here is defining a business object that when properties are set, the raisePropertyChanged (propertyName) method provided by the base class is executed. This notifies any bindings bound to this property to update themselves. Once I’ve defined my business object in this manner, it can participate in bindings just like other Atlas components. By changing the binding’s direction to InOut, I could even update my business object with a user entered value. This would be useful for capturing data and placing it in a client side business object for validation.

While this works, defining all of my business objects that need to participate in clientside binding is a bit tedious. Also, if I am able to serialize my objects to JSON on the server and then emit the necessary JavaScript to place them on the client then defining them on the client isn’t really necessary as the deserialized JSON statement is already an object. All I need to know is the makeup of my server object to access the data on the client. But, to make them bindable I have to go through the definition process on the client. Ugh! Furthermore, it kills maintainability as if I add or remove a property from the server object I have to update the client object too. Double Ugh! If I can figure out a way to do something like this … “var bindableObject = new BindableObject (keyword);” and then have all the pieces of keyword become bindable, that would be most excellent.

That will be the subject of my next blog. If I can figure it out…

Comments??