Today, as I was browsing Google News, I stumbled across a heading/image pair that didn't quite seem to match well:

....I would really hate to encounter those "South Bay authorities" in a dark alley somewhere....

So, I got to reading a couple blog posts this weekend and one of them (which I found from dotnetkicks.com) was interesting. It presented a problem that I've encountered before but always skirted architecturally (I just changed the design of my web application a bit so I wasn't faced with it anymore). I got to thinking about a few ways to solve this issue and one way popped out at me as one way - but not necessarily the best way (possibly not even close, in certain circumstances). Anyway, I'm presenting it here to open the discussion up if anyone wishes, but otherwise to just write it down so that I have it here for later reference.

The Problem

You cannot easily reference objects from client script if their server-side counterparts are housed within certain parent controls. For example, if you place a TextBox control within a Wizard control and then attempt to reference that TextBox control from client script, you will undoubtedly have difficulties.

Why?

When the control is rendered out to the browser, it's client-side ClientID will not be the same as it's server side ClientID for various reasons. Suffice it to say that if you name a TextBox "MyTextBox", place it within a Wizard control, and then attempt to reference that control from client script with the ID "MyTextBox" it will fail (for the sake of posterity, the name of the TextBox will probably be the name of the wizard + underscore + "MyTextBox").

This is obviously a problem if you're writing script to reference objects through the $get() shortcut handler, etc.

One Solution

One solution is to not use ID as the reference attribute, but to instead add some other attribute and reference controls that way. Now, I'm not sure how browser-compliant this nor how standards compliant it is, but it works for me locally and I thought I'd at least mention it for those who may be on their last leg trying to back out of a problem like this. I just picked a random attribute name "googliebah" and decorated a couple controls on my page with it; then my custom script will locate a control with the googliebah ID and then determine if its value matched the search value. Obviously it works.

Now, in terms of efficiency I can't say this ranks as a an optimal solution; but perhaps a more eager person could introduce some level of caching the elements once they're found (or limiting the scope of the objects you're searching by doing some post-processing on the ASP.NET page). I have a few ideas around that solution, but I can't say as though I have the time at the moment to implement them.

Regardless, this is the script:

        <script type="text/javascript">
            function newFind(name)
            {
                var elems = document.getElementsByTagName('*');
                var num = elems.length;
                for(var c=0;c<num;c++)
                {
                    var val = elems[c].getAttribute('googliebah');
                    if(val!=null && val==name)
                        return elems[c];
                }
            }
        </script>

And you use it to find some control like this:

<div googliebah='test' id='test' class="title">

By doing something like this:

<input id="Button2" onclick="var elem = newFind('test'); if(elem)alert(elem.id);" ....

In this post, I'm going to end my discussion on Animations in ASP.NET AJAX by showing you how they work, internally. At the end of this post you should not only know how Animations work, but also how ExtenderControl's work in general.

What is an ExtenderControl?

An Animation is actually just an ExtenderControl, so it will do us some good to understand what an ExtenderControl is all about.

ExtenderControls are script controls that apply a particular feature from ASP.NET AJAX to an already existing ASP.NET (non-AJAX) control. For example, if you wanted to apply some cool, new feature of ASP.NET AJAX to a standard radio button control, you'd do so through the implementation of an ExtenderControl. Extender control's work by emitting JavaScript that is attached to and extends functionality of an ASP.NET control. You will always need to reference the control to which you are applying the extender because it will need to know which control the emitted script should target. The key thing to remember is that it's an ExtenderControl is an auxiliary to an existing control, and typically the extending features are done through JavaScript.

Exactly how does the script emitted by an ExtenderControl become attached to the target ASP.NET control? Script becomes successfully attached to pre-existing controls through the runtime execution of the ScriptManager on the server, the use of a type known as the ScriptDescriptor, and the bootstrap client-side code of ASP.NET AJAX on the client.

On the server, the process looks something like this

The process starts when the ASP.NET runtime asks the ScriptManager (a native, server-side control) to render itself out. The result of doing so causes the ScriptManager to ask every control that has attached itself to the ScriptManager to render itself out too (an Animation, being an ExtenderControl, is therefore asked to render).

A script control is a special, new type of control introduced into the ASP.NET AJAX framework as a control that relies heavily on the scripting facilities of ASP.NET AJAX. One of the important features of a script control that sets it apart from other controls is that it has a great deal of functionality that must be executed on the client (through JavaScript) for it to function properly. A script control is responsible for giving all scripts and script types it requires to operate to the ScriptManager when it renders; doing so guarantees that the script will be included in the page output and therefore included in the rendered page.

Script controls hand off all the necessary script and script types to the ScriptManager as nicely packaged objects known as ScriptDescriptors and ScriptReferences.  We’re more interested in ScriptDescriptors, however, as they are the layout for the JavaScript types and so (if you refer to the diagram above) you see that our extender control (when asked to render) calls back into the ScriptManager to register all its types. Doing so finally calls into ScriptDescriptor.GetScript() which returns back a block of script leveraging the $create() shortcut method and a series of JSON-formatted data.

When the ScriptManager renders, then, it guarantees that the JSON-formatted data of the control will be instantiated and initialized on the client through the $create() method. How? Because the ScriptManager will wrap the output of GetScript around the Sys.Application.add_init() javascript method. Add_init() actually attaches code to the initialization script of ASP.NET AJAX’s client libraries; this guarantees that, when ASP.NET AJAX is fully started up on the client when the page has fully loaded, your initialization routine will be called. What the initialization routine does, however, is up to you.  

How Does an Animation Work?

You're 90% of the way to understanding Animations now. All that's really required is a bit of a filler-explanation for what, specifically, the Animation extender control is doing.

On the server the Animation control will take your XML markup and create an in-memory Animation object instance representing all of the properties and child/parent associations. Since an Animation is an extender control, the ScriptManager will ask it to render. The result of the Render call will be the JSON-formatted version of the Animation object from the server (property values, event-handling code and all). Just like above, the JSON-formatted initialization code will be wrapped around a Sys.Application.add_init() script method so that it will be executed when the page is loaded on the client. This is an example of what the output looks like:

…this is actually the result of a view source on one of the animation examples on www.asp.net. There is a lot of code here, but if you squint carefully you can see it all starts with a Sys.Application.add_init() call. Also if you look carefully you’ll see that it’s actually instantiating, on the client, an object of type AjaxControlToolkit.Animation.AnimationBehavior.

The AnimationBehavior Object

If you recall from earlier discussions about Animations, there are actually many instances where multiple animation effects (a fade out, or a color change) can occur in sequence as the result of a single event (onclick). Each animation effect is actually an Animation object, and the object that surrounds each Animation (to make them happen in sequence) is also an Animation object – so we have Animation objects housing multiple Animation objects. This can be confusing when rendered out to the client, so the ASP.NET AJAX client framework wraps all the animations that need to be rendered to the client for a single Animation extender as an AnimationBehavior object. The AnimationBehavior object is what gets instantiated on the client and has its initialize() method called.

The initialize() method of the AnimaitonBehavior object will inspect which events need to be registered (OnClick, etc) and attach event handlers to the target control on the page (the client-side control which we’re extending). Whenever that event occurs on the client, the event handler for the AnimationBehavior will be called and it will route that event to the proper Animation object. Here is an example of the AnimationBehavior’s OnClick event hander:

…which, after a bit more traversing the internals of the script library, plays the Animation.

How does the Animation object actually play the animation?

It may seem like somewhat of a mystery when you declare XML on your page that then translates into some dynamically updating DHTML object, but if you think carefully about what it take to animate a DHTML object the mystery subsides.

All that it takes to animate something on your page is a timer ticking at a regular interval whose callback method updates some DHTML object property (x- and y-position, for example). And that’s all an Animation object is on the client – just a fancy timer that updates properties with values you specify; invoking the play method above simply starts off the timer, and thus the DHTML effects. Therefore all that’s needed within the JSON data is enough information to identify what property you’re updating on what object, at what interval, and with what values – the existing script of the Animation object will take care of the rest. If you look at some of the JSON-serialized data that is being rehydrated on the client, you actually can see just that information (take a closer look):

..and that’s how Animations work.

The CollapsiblePanel is an ASP.NET AJAX extender control in the AJAX Control Toolkit. This particular extender control extends the default behavior of the standard ASP.NET Panel to collapse and expand when a particular element on the page is clicked (it will scroll open or closed when this trigger element is clicked). It's very easy and elegant to use, but one common question seems to be - when a full post back is triggered - what is the current (or most recent) state of the panel - collapsed or expanded?

The way to find out is by inspecting the ClientState property on the CollapsiblePanel's instance:

If ClientState is true, then the panel is collapsed; if the ClientState is false, then the panel is expanded.

In my first post in this series on using ASP.NET AJAX animations I described the basics of what an Animation was and the foundations behind using it. In my second post, I then started showing you how to go about using it (the basics). What remains are a few exceptional Animations that will be used in unusual circumstances (hence them being "exceptional") but which enable you with a great deal of power when you do decide to use them.

The Condition Animation

Why stop a good thing? So I'm going to continue using the (somewhat lame) example from my previous posts where I take a simple ASP.NET button control and do things to it using the Animation framework. In this example I leverage an animation called the Condition Animation; it gives you the ability to programmatically choose one of two (at most) animations to run depending on the boolean result of some script. For example, take the following Animation XML:

By clicking button Button1, the Condition Animation will be executed (if this block doesn't make sense, see my first post and read forward). Take note of the Condition Animation and it's child Animations. The first thing to take note of is the ConditionScript attribute on the Condition element; it's a simple statement: "false;". Although this is just a boolean result (false), it could be an entire JavaScript statement which evaluates to either true or false. For Condition Animations, if the resultant script statement evaluates to true, then the first child Animation is executed (in this sample, the FadeOut animation); if the script statement evalutes to false, then the second child Animation (which is the Color animation) would be executed.

Given that you now have programmatic control over what Animation is executed, you can take conditions on the page, evaluate them through the script, and then decide which Animation to run.

The Case Animation

Being limited to one of two Animations is, well limiting. In the event that you need to pick from a wider spectrum of Animations, but still do so using the result of a script statement, then you would leverage the Case Animation. Take the following XML Animation block:

The result of the SelectScript must be a 0-based index into the array of child Animations (0 is the first Animation or the "FadeOut" animation, 1 is the second animation or the "Color" animation in our example, and so forth). In my example I simply return "1" but, like the Condition Animation above, you could have an entire script statement as the SelectScript value. So long as your script statement evaluates to a valid index into the array of child Animations beneath your Case animation it will behave properly.

In the above example, the Color animation will be executed.

The Script Animation

To flat out execute script in the Animation you would leverage the Script Animation. Take the following example:

What we have here is a Sequence Animation housing a FadeOut and then a ScriptAction animation. Given what we already know about a Sequence animation, the child nodes (or child Animations) will be executed sequentially from top to bottom. Therefore, when Button1 is clicked, the Button will fade out over half a second and then a script modal window will pop up saying "All done". Of course, much more advanced script could be executed from the ScriptAction, but you get the basic idea.

What's Next?

Okay, next we are going to dive into the pipeline to see just how this magic is done. Stick around...

If you get MSDN, you can read my new article "ASP.NET ScriptManager Enables AJAX in your web apps". It received top billing in the September issue of MSDN.

If you have feedback, please post it here - I have another article planned soon.

I'm starting another blog on the business/psychology/technology of the new social web over here. The purpose of it is to be less nuts and bolts and more study of the interplay between the business, technology and psychology of the Web 2.0 world. I'm going to analyize, break-down and study as much as I can about that world and hopefully open up some interesting dialog as the blog continues to grow.

...I have become more and more interested in that business/psychology/technology aspect of web world lately and have been wanting to study it more (and thus write about it). However, I didn't want to muddy up the point of this blog as a place for people to go to understand the under-the-hood pieces of Microsoft .NET technologies, so I just created a second one.

I invite you to come on over when you have a chance, I'll be posting regularly and - hopefully - have some interesting things to say.

In my previous post I gave a brief overview of what an Animation is in ASP.NET AJAX, and now it's time to understand how you go about actually using them. By the end of this post you should be able to look at a block of Animation XML and understand what it's doing and you should be able to write a block of Animation XML without needing to lookback on a sample block of code (too much).

Let's Recap for a Moment

Before diving, let's recap from my previous post: an Animation in the ASP.NET AJAX framework is any DHTML effect that leverages the Animation framework provided by the ASP.NET AJAX toolkit (which can be found here). The problem found in playing with DHTML in the past has been that you've needed JavaScript (and sometimes pretty hairy JavaScript) to do anything meaningful with it. As programmers we're "resourceful" (or lazy) and therefore don't want to do more work than we need. With the Animation framework in ASP.NET AJAX, you only need to worry about XML markup specific to the animation you want.

In short, ASP.NET AJAX Animations are the easy way of adding cool DHTML animations and effects to your page - it achieves this by letting you define and play with your animations declaratively through an XML syntax.  

Show Me an Example

Let's go back to an earlier example that I did (because of its utter simplicity) and work out from there. In my previous post I showed an example effect on a button where, once you clicked the button, it's text color changed red and then faded out:

to....

You achived this effect by using declarative XML syntax. The syntax let you play with the properties (the starting color and ending color in this example) without needing to write any code; thereby making things easier and more manageable for everyone. Let's break the syntax I showed you earlier down one element at a time so that you can see why a particular element exists and what it does.

Understanding the ASP.NET Animation XML Syntax

As I said earlier, to write an Animation in ASP.NET AJAX, you use an XML syntax. The syntax that resulted in the above button color change looks like this:

First thing to take away is that this is a control extender - or an object in the ASP.NET AJAX framework that let's you apply AJAX'ish properties to an already existing, standard ASP.NET control (you can learn more about extenders here). What this means, practically, is that the animation needs to know to what standard ASP.NET control the animation will be applied. If you take a look at the first line of XML, you'll see the TargetControlID property pointing to Button1. You should know that this Animation will, then, be applied to Button1.

Second is the Animations element which will house all of the animations you will apply to Button1 (that's right, you can apply more than one, even in parallel). This may seem somewhat redundant, but it is required.

Third we have an event name. In our example, OnClick, means that the Animations will be executed during the OnClick event of Button1 (bear in mind that this is the client onclick event, not the server one). Therefore when someone clicks Button1, the animations specified below the OnClick event node will be executed.

The events OnClick, OnLoad, OnMouseOver, OnMouseOut, OnHoverOver and OnHoverOut are valid events; meaning you don't have to just use OnClick, you could also use OnHover. It's interesting to note that you can have all of these event handlers under the same Animations element if you wanted to - therefore, you could have one Animation registered for OnClick, and a totally different one registered for OnMouseOver, thereby creating a very dynamic control!

Fourth we have a sequence element; but - I have to admit to something here, this is actually not necessary in our example. I added it because I wanted to make a point about something. The point I want to make is a subtle one: you can only have one Animation registered for a particular event type (OnClick, OnMouseOver). The reason this isn't a limitation, however, is because there are two Animations called Sequence and Parallel which are not only valid Animations themselves, but allow nesting of other animations. Therefore, Sequence is an Animation itself that will call each child Animation one after another (in "Sequence"), and Parallel is an Animation that will call each child Animation at the same time (in "Parallel"). This is a subtle, yet powerful, thing to realize.

So..the following XML is actually valid (note the missing Sequence element):

But, if you wanted to change the color of the button and THEN fade it away completely, for example, you would have to nest the Color Animation and FadeOut animation within a Sequence Animation (not doing so will result in a runtime exception). The XML must look like this:

The result from the above XML declaration is to fade the button's color from FF0000 to 666666 and then completely fade it out of existence in .5 seconds. What's really cool is if you wanted to do both at the same time, all you have to do is change the Sequence element to a Parallel element:

Cool, huh? Now the color change and the fade-to-nothing will happen at the same time or in Parallel.

The lowest level element of the structure is always the actual Animation itself (Color for color change, FadeOut for fading out the element, etc).

Does it Get Tougher?

Yes, somewhat because you can actually tie into the XML script to be executed when certain events occur and conditional statements. We'll explore that, however, next time...