What popped into my head is the “Tell Me Everything You Know…” methodology. My goal when I would interview somebody is to, in the shortest amount of time, figure out everything this person knows about technical things that indicate if the person is a standout developer or not.

Here’s the basic interview structure:

I’d tell them we were going to have a series of 5 minute conversations and in those 5 minute conversations they were supposed to tell me everything they know about whatever I asked them. Rather than taking notes, the conversation is recorded because this is going to happen way too fast for me to write anything down. Plus, I’ve found out over the years that notes I’ve written about most things are incomplete and tend to stall conversations.

What I’m going to be able to tell during this conversation is if they can communicate effectively, context switch quickly, respond to a bit of pressure, and if they have the technological chops I’m looking for. I’d say that the last one is the most important, but in my company if you can’t write a good email or switch your focus quickly, you’re kind of useless. This is the extend of how I would hire a developer. It sounds simplistic, but in my head it works.

Here’s my list of topics that I’d ask about. Everyone’s will be different, but these are ones that are important to me.

Tell Me Everything You Know About …

The Sessions were expiring because the user wasn’t causing a postback (full or partial) and thus executing the ASP.NET page life cycle, which takes care of maintaining Session for us by implementing the IRequireSessionState interface.

One way I could have solved this problem is to rehydrate Session whenever an Ajax request was received (such as by marking the web method as requiring Session), but this is a bad programming practice for a few reasons. First, having Session attached to a request and response isn’t very RESTful and breaks at least a couple of design rules. Second, it’s a relatively expensive operation to pull Session from the session store, deserialize it into the Session object, use it, maybe modify it, and then serialize it back out to the Session store when the request is complete. As Session gets bigger, this operation gets more expensive and I really want the Ajax features of the application to fly. Finally, I might not own the REST endpoints that I’m using for my application’s functionality. In that case, I’m talking to a third party service (i.e. Amazon’s S3 service), and not communicating at all with my application, but I still need to keep Session alive. The user doesn’t know or care that I’m talking to Amazon. They just think they’re using my application.

What I really wanted to do was sometimes revalidate Session while the user interacted with the Ajaxy parts of the application without the user paying any perceivable performance penalty and not breaking too many rules of application design.

To do this, I created a mechanism to execute a fire and forget request to a custom Http Handler that takes care of revalidating Session for us.

[Download the code here]

First, let’s cover the the custom Http Handler:

using System.Web;
using System.Web.SessionState;

public class OutOfBandSessionValidator : IHttpHandler, IRequiresSessionState
{
    public bool IsReusable
    {
        get { return false; }
    }

    public void ProcessRequest(HttpContext context)
    { }
}

As you can see, out OutOfBandSessionValidator does almost nothing. The only thing really worth noting is that it implements the IRequiresSessionState interface that tells ASP.NET that when a request comes in, this handler requires that Session be retrieved and deserialized, and when the request completes, it serializes the Session object and stores it back in the Session store. This is the mechanism that will allow us to keep Session alive.

We wire up out custom handler just like any other Http Handler in the web.config like so:

<httpHandlers>
...
    <add verb="GET,HEAD" path="OutOfBandSessionValidator.ashx" type="OutOfBandSessionValidator"/>
...

</httpHandlers>

(This is IIS 6 style.)
We can now access our custom handler like so: http://localhost:1544/OutOfBandSessionValidator.ashx

Now that we’ve got our handler wired up, we need to create a mechanism to call it. For performance purposes, we want to call the handler in a way that doesn’t affect our application’s performance (perceived or real) and we don’t want to call it too often. Rather, we want to call it once a minute or something like that. We’re going to wrap this functionality in a custom component. In the custom component we’re going to reply on a Client EventPool event to talk to our component rather than call into it directly. This way, we don’t really need to have a link to the component.
First, for posterity, let’s redefine our Client EventPool. (For more information on the Client EventPool, see this post.)

_EventPool = function() {
    _EventPool.initializeBase(this);
};
_EventPool.prototype = {
    addEvent: function(name, handler) {
        this.get_events().addHandler(name, handler);
    },
    removeEvent: function(name, handler) {
        this.get_events().removeHandler(name, handler);
    },
    raiseEvent: function(name, source, args) {
        var handler = this.get_events().getHandler(name);
        if (handler) {
            handler(source, args);
        }
    }
};
_EventPool.registerClass("_EventPool", Sys.Component);
var $evp = $create(_EventPool, { "id": "EventPool" }, null, null, null);

Now we can define our OutOfBandSessionValidator component and a custom event args class:

RevalidateSessionArgs = function(ticks) {
    RevalidateSessionArgs.initializeBase(this);
    this._ticks = ticks;
};
RevalidateSessionArgs.prototype = {
    get_ticks: function() { return this._ticks; }
};
RevalidateSessionArgs.registerClass("RevalidateSessionArgs", Sys.EventArgs);

_OutOfBandSessionValidator = function() {
    _OutOfBandSessionValidator.initializeBase(this);
    this._revalidateSessionDelegate = null;
    this._lastTimeSessionWasValidated = null;
    this._delay = 60000; // default to 60 seconds.
};

_OutOfBandSessionValidator.prototype = {
    set_delay: function(value) { this._delay = value; },
    get_delay: function() { return this._delay; },

    initialize: function() {
        _OutOfBandSessionValidator.callBaseMethod(this, 'initialize');
        this._revalidateSessionDelegate = Function.createDelegate(this, this._revalidateSession);
        $evp.addEvent("RevalidateSession", this._revalidateSessionDelegate);
    },

    dispose: function() {
        if (this._revalidateSessionDelegate !== null) {
            $evp.removeEvent("RevalidateSession", this._revalidateSessionDelegate);
            this._revalidateSessionDelegate = null;
        }
        _OutOfBandSessionValidator.callBaseMethod(this, 'dispose');
    },

    _revalidateSession: function(sender, args) {
        Sys.Debug.trace("_revalidatingSession");
        var revalidate = false;
        if (this._lastTimeSessionWasValidated === null) {
            revalidate = true;
        }
        else if ((args.get_ticks() - this._lastTimeSessionWasValidated) > this._delay) {
            revalidate = true;
        }

        if (revalidate) {
            Sys.Debug.trace("Executing call to OutOfBandSessionValidator.ashx");
            this._lastTimeSessionWasValidated = args.get_ticks();
            var wRequest = new Sys.Net.WebRequest();
            wRequest.set_httpVerb("GET");
            wRequest.set_url("OutOfBandSessionValidator.ashx?d=" + args.get_ticks());

            var executor = new Sys.Net.XMLHttpExecutor();
            wRequest.set_executor(executor);
            executor.executeRequest();
        }
    }
};
_OutOfBandSessionValidator.registerClass("_OutOfBandSessionValidator", Sys.Component);
$create(_OutOfBandSessionValidator, { "id": "OutOfBandSessionValidator" }, null, null, null);

The _OutOfBandSessionValidator component is quite simple. In it's initialize method we wire up a delegate to the "RevalidateSession" event

initialize: function() {
    _OutOfBandSessionValidator.callBaseMethod(this, 'initialize');
    this._revalidateSessionDelegate = Function.createDelegate(this, this._revalidateSession);
    $evp.addEvent("RevalidateSession", this._revalidateSessionDelegate);
},

In the dispose method we clear out this event handler

dispose: function() {
    if (this._revalidateSessionDelegate !== null) {
        $evp.removeEvent("RevalidateSession", this._revalidateSessionDelegate);
        this._revalidateSessionDelegate = null;
    }
    _OutOfBandSessionValidator.callBaseMethod(this, 'dispose');
},

The other method, _revalidateSession, which is executed whenever the “RevalidateSession” event is raised, is responsible for calling our OutOfBandSessionValidator handler not more than whatever delay we set.

_revalidateSession: function(sender, args) {
    Sys.Debug.trace("_revalidatingSession");
    var revalidate = false;
    if (this._lastTimeSessionWasValidated === null) {
        revalidate = true;
    }
    else if ((args.get_ticks() - this._lastTimeSessionWasValidated) > this._delay) {
        revalidate = true;
    }

    if (revalidate) {
        Sys.Debug.trace("Executing call to OutOfBandSessionValidator.ashx");
        this._lastTimeSessionWasValidated = args.get_ticks();
        var wRequest = new Sys.Net.WebRequest();
        wRequest.set_httpVerb("GET");
        wRequest.set_url("OutOfBandSessionValidator.ashx?d=" + args.get_ticks()); 

        var executor = new Sys.Net.XMLHttpExecutor();
        wRequest.set_executor(executor);
        executor.executeRequest();
    }
}

In the _revaidateSession method, the args parameter is of type RevalidateSessionArgs. This custom arguments class contains one property, get_ticks(), which simply holds a ticks value. This value’s intended purpose is to hold the current ticks of the date/time when of when the event args were created. It then performs some checking to make sure that we haven’t initiated a request to OutOfBandSessionValidator.ashx with the delay and then sends a non-cacheable GET request to the OutOfBandSessionValidator.ashx handler.

To use the OutOfBandSessionValidator we raise the RevalidateSession event like so:

$evp.raiseEvent("RevalidateSession", this, new RevalidateSessionArgs(new Date().getTime()));

Now that we have a mechanism for calling the OutOfBandSessionValidator.ashx by raising an event, we can write a small test page that raises the event every 5 seconds. To really illustrate that our mechanism works, we’re going to set the ASP.NET Session timeout to 1 minute in the web.config file.

        <sessionState  mode="InProc" cookieless="true" timeout="1" />
    </system.web>

Here’s our test page’s markup. Note that we have three buttons on the page. The first one causes postback and refreshes the label with the current Session’s information. The other two start and stop the raising of the event.

<body>
    <form id="form1" runat="server">
    <asp:ScriptManager ID="SM1" runat="server">
        <Scripts>
            <asp:ScriptReference Path="~/JS.js" />
        </Scripts>
    </asp:ScriptManager>
    <div>
        <asp:Label ID="lblNewSession" runat="server" />
        <asp:Button ID="btnCausePostback" runat="server" Text="Cause Postback" />
    </div>
    <input type="button" id="btnStopInterval" disabled='disabled' value="Stop Interval"
        onclick="window.clearInterval(window._intervalId);
                 $get('btnStartInterval').disabled = false;
                 $get('btnStopInterval').disabled=true; " />
    <input type="button" id="btnStartInterval" value="Start Interval"
        onclick="window._intervalId=window.setInterval(window.fn, 5000);
        $get('btnStartInterval').disabled = true;
        $get('btnStopInterval').disabled = false;" />
    </form>
</body>

Here’s the test page’s code behind.

public partial class _Default : Page
{
    protected void Page_Load(object sender, EventArgs e)
    {
        Session["lastAcessTime"] = DateTime.Now;
        if (this.Session.IsNewSession)
        {
            this.lblNewSession.Text = "New Session: " + this.Session.SessionID;
        }
        else
        {
            this.lblNewSession.Text = "Existing Session: " + this.Session.SessionID;
        }
    }
}

Here’s how the page looks when we initially load it.

After waiting 30 seconds or so, and clicking the “Cause Postback” button, we see that we’re working with an existing Session.

After waiting more than one minute and clicking the “Cause Postback” button, we see that the Session is again new.

Now we turn on the interval that is going to raise our RevalidateSession event by clicking the “Start” button.

Note: for this test, I reduced the delay between requests from 60 seconds to 20 seconds.
Looking at the debug window of Visual Studio, we can see that our event is being raised every 5 seconds, but besides the first request, not until the 4th request (20 second mark) do we see the debug message that we’ve initiated a request to the OutOfBandSessionValidator.ashx.

Again, after another 4 requests we see the request to the OutOfBandSessionValidator.ashx

Now when I click the “Cause Postback” I get the existing Session message

When I click the “Stop” button, wait about a minute or so and then click the “Cause Postback” button, you’ll see that the Session has started over.

So there you have it. My take on how to keep an ASP.NET Session alive in an Ajax application.

My final thought is this. It doesn’t make much sense to raise the event every 10 seconds or something like in order to keep the Session alive. Session timeouts are there for a reason. If you never wanted the Session to timeout a better way would be to increase the Session timeout to some ridiculous number. Rather, it is much better to raise the event in response to a user’s action. The user panned the map, requested a property detail, clicked a drop down list, etc. If you get real clever, you’ll figure out that you should centralize this event raising and figure out a way to write the code once and have it executed automatically.

In a past post, I highlighted a problem with the method ASP.NET AJAX uses to determine if the DOM is ready to be modified. (Other developers have since commented that they’ve seen this problem in the wild.) I followed that post with another one where I provided code changes to fix the problem. Through comments on that post, talking with other developers, and reading other people’s blogs, I determined that it was a little bit unelegant and didn’t take into account all situations.

So, I wanted to take a few minutes and revisit this topic; hopefully for the last time, and provide a more complete ASP.NET AJAX solution for this problem.

The code I’m about to cover wasn’t designed, developed, or thought up by me. Rather it’s a mis-mash of different developers working on a problem. You could say it’s open source at its best. The code I’m actually going to provide comes from Diego Perini. He has put together a complete solution that works across all browsers. He, in turn, borrows from Dean Edwards and others.

So, I’ve adapted his code to the ASP.NET AJAX environment.

First, here’s the new version of Sys.Application.initialize:

  function Sys$_Application$initialize() {
      if(!this._initialized && !this._initializing) {
          this._initializing = true;
          var u = window.navigator.userAgent.toLowerCase(),
              v = parseFloat(u.match(/.+(?:rv|it|ml|ra|ie)[\/: ]([\d.]+)/)[1]);

          var initializeDelegate = Function.createDelegate(this, this._doInitialize);
          
          if (/WebKit/i.test(u) && v < 525.13) 
          { 
              this._load_timer = window.setInterval(function() 
              {
                  if (/loaded|complete/.test(document.readyState))
                  {
                      initializeDelegate(); 
                  }
              }, 10);
          }
          else if (/msie/.test(u) && !window.opera)
          {
              document.attachEvent('onreadystatechange',
                  function (e) {
                      if (document.readyState == 'complete') {
                          document.detachEvent('on'+e.type, arguments.callee);
                          initializeDelegate();
                      }
                  }
              );
              if (window == top) {
                  (function () {
                      try {
                          document.documentElement.doScroll('left');
                      } catch (e) {
                          setTimeout(arguments.callee, 10);
                          return;
                      }
                      initializeDelegate();
                  })();
              }

          }
          else if (document.addEventListener
              &&  ((/opera\//.test(u) && v > 9) ||
                  (/gecko\//.test(u) && v >= 1.8) ||
                  (/khtml\//.test(u) && v >= 4.0) ||
                  (/webkit\//.test(u) && v >= 525.13))) {
              document.addEventListener("DOMContentLoaded", initializeDelegate, false);
          }
          else
          {
              $addHandler(window, "load", initializeDelegate);
          }   
      }
  }

Here’s the _doInitialize method:

  function Sys$_Application$_doInitialize() {
       if (this._initialized) {
           return;
       }
       Sys._Application.callBaseMethod(this, 'initialize');
       if (this._load_timer !== null)
       {
           clearInterval(this._load_timer);
           this._load_timer = null;
       }
       var handler = this.get_events().getHandler("init");
       if (handler) {
           this.beginCreateComponents();
           handler(this, Sys.EventArgs.Empty);
           this.endCreateComponents();
       }
       if (Sys.WebForms) {
           this._beginRequestHandler = Function.createDelegate(this, this._onPageRequestManagerBeginRequest);
           Sys.WebForms.PageRequestManager.getInstance().add_beginRequest(this._beginRequestHandler);
           this._endRequestHandler = Function.createDelegate(this, this._onPageRequestManagerEndRequest);
           Sys.WebForms.PageRequestManager.getInstance().add_endRequest(this._endRequestHandler);
       }
       
       var loadedEntry = this.get_stateString();
       if (loadedEntry !== this._currentEntry) {
           this._navigate(loadedEntry);
       }

       this.raiseLoad();
       this._initializing = false;
   }

Finally, here’s the Sys.Application._loadHandler method, which hasn’t changed since the first version.

function Sys$_Application$_loadHandler() {
    if(this._loadHandlerDelegate) {
        Sys.UI.DomEvent.removeHandler(window, "load", this._loadHandlerDelegate);
        this._loadHandlerDelegate = null;
    }
    this._initializing = true;
    this._doInitialize();
}

Just like last time, the majority of the work takes place in the initalize method.

Good luck and thanks for putting it together Dave!

First, sources at Microsoft confirmed this bug for me and said that a fix was already completed for v-next. I’m not sure when the next release will take place; if it will be with VS 2010 or sometime earlier, but they have it fixed.

Second, Jason Kealey has a fix that is less intrusive than the one I suggested here. You can find it here

Since the rest of the tech-world is talking about and trying Google Chrome, I thought that I’d give it a whirl and see how it interacted with ASP.NET AJAX. I’ve worked on a couple of ASP.NET AJAX applications for work (including a public website: http://showcase.costar.com) and have a bunch of small test application that I’ve written for other purposes and was curious to see how those held up when accessed with Chrome. For the most part, with the smaller applications the browser worked as expected. I had almost no layout issues (as we program for IE6, IE7, FF2, and FF3) and almost no JS problems. But, when I ran ShowCase, which uses UpdatePanels to load large swathes of a page and in doing so loads external scripts dynamically, the application broke when accessing the mapping portion of the application. Since I was responsible for this part of the application, I needed to investigate further.

Through Fiddler, which Chrome interacts with nicely by default, I discovered that my scripts weren’t loading. Furthermore, through Chrome’s JavaScript console I learned that a JS error was being thrown. The error thrown was the one where it says the external script at xyz.js doesn’t contain a call to Sys.Application.notifyScriptLoaded(). Well, all my scripts contain this call and so this was a red herring, but set me in the right direction.

Thinking about it, I remembered that script loading during a partial postback is a browser specific task and I wondered what code path Google Chrome was following since it isn’t a known browser to ASP.NET AJAX. The first thing I needed to discover was what browser ASP.NET AJAX thought it was interacting with. To my surprise, ASP.NET AJAX thought Chrome was Safari.

I discovered this using Chrome’s JavaScript console and executing the “Sys.Browser.name” command, which outputted the value “Safari.” (BTW, the IntelliSense in the console window is amazing.) At first, I thought that Safari might be the default browser when the ASP.NET AJAX code can’t figure out what browser it really is. While this would be a bit strange, maybe it made sense when MSFT developed ASP.NET AJAX. So I went hunting inside of MicrosoftAjax.js to figure out why ASP.NET AJAX thought that Chrome was Safari and came to this code.

if (navigator.userAgent.indexOf(' MSIE ') > -1) {
    Sys.Browser.agent = Sys.Browser.InternetExplorer;
    Sys.Browser.version = parseFloat(navigator.userAgent.match(/MSIE (\d+\.\d+)/)[1]);
    if (Sys.Browser.version >= 8) {
        if (document.documentMode >= 7) {
            Sys.Browser.documentMode = document.documentMode;
        }
    }
    Sys.Browser.hasDebuggerStatement = true;
}
else if (navigator.userAgent.indexOf(' Firefox/') > -1) {
    Sys.Browser.agent = Sys.Browser.Firefox;
    Sys.Browser.version = parseFloat(navigator.userAgent.match(/ Firefox\/(\d+\.\d+)/)[1]);
    Sys.Browser.name = 'Firefox';
    Sys.Browser.hasDebuggerStatement = true;
}
else if (navigator.userAgent.indexOf(' AppleWebKit/') > -1) {
    Sys.Browser.agent = Sys.Browser.Safari;
    Sys.Browser.version = parseFloat(navigator.userAgent.match(/ AppleWebKit\/(\d+(\.\d+)?)/)[1]);
    Sys.Browser.name = 'Safari';
}
else if (navigator.userAgent.indexOf('Opera/') > -1) {
    Sys.Browser.agent = Sys.Browser.Opera;
}

Obviously, my initial assertion that Safari might be the default was wrong. Seeing that the code uses the userAgent string to determine the browser, I grabbed the userAgent string of Chrome request in Fiddler:

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/525.13 (KHTML, like Gecko) Chrome/0.2.149.27 Safari/525.13

As the code above shows, it parses the userAgent string looking for the word ” AppleWebKit/” and if found (once it didn’t find ” MSIE ” or ” Firefox/”) the if-then logic determined that the browser is Safari. Now that I understood why ASP.NET AJAX thought that Chrome was Safari, I also had an idea about why my map was failing to load.

Searching through MicrosoftAjax.js, I found that there are three code paths that being a “Safari” browser alters.

1. JSON Serialization
2. External script loading and script text processing during a partial postback
3. Getting a location of an element

Obviously, since the culprit of my problem was that my external scripts weren’t being loaded during a partial postback, this was the problem I needed to fix. Without knowing exactly what to do, I decided to see if I loaded external script using the default code path instead of the Safari code path, would the scripts load properly. To achieve this I needed to get Chrome to not be recognized as Safari so it would go down the default code path.

To add the Chrome browser to ASP.NET AJAX, there are two basic steps.

1. Add a new browser type

Sys.Browser = {};
Sys.Browser.InternetExplorer = {};
Sys.Browser.Firefox = {};
Sys.Browser.Safari = {};
Sys.Browser.Opera = {};
Sys.Browser.Chrome = {};

2. Update the if-then logic to search for Chrome

else if (navigator.userAgent.indexOf(' Firefox/') > -1) {
    Sys.Browser.agent = Sys.Browser.Firefox;
    Sys.Browser.version = parseFloat(navigator.userAgent.match(/ Firefox\/(\d+\.\d+)/)[1]);
    Sys.Browser.name = 'Firefox';
    Sys.Browser.hasDebuggerStatement = true;
}
else if (navigator.userAgent.indexOf(' Chrome/') > -1) {
    Sys.Browser.agent = Sys.Browser.Chrome;
    Sys.Browser.version = parseFloat(navigator.userAgent.match(/ Chrome\/(\d+\.\d+)/)[1]);
    Sys.Browser.name = 'Chrome';
    Sys.Browser.hasDebuggerStatement = true;
}
else if (navigator.userAgent.indexOf(' AppleWebKit/') > -1) {
    Sys.Browser.agent = Sys.Browser.Safari;
    Sys.Browser.version = parseFloat(navigator.userAgent.match(/ AppleWebKit\/(\d+(\.\d+)?)/)[1]);
    Sys.Browser.name = 'Safari';

Notice how the Chrome check has to go before the Safari check.

(This is basically the same pattern that’s talked about here for Safari 3 before .NET 3.5 SP1 came out. Has anybody else noticed the decreasing font size in the ASP.NET forum’s when viewing with Chrome?? Hilarious)

Now, when we run an ASP.NET AJAX site using our custom MicrosoftAjax.js file (to see how to replace Framework scripts with custom ones, read this article), Sys.Browser.name returns “Chrome.”

So back to ShowCase. Using my customized MicrosoftAjax.js file, ShowCase mapping worked like a champ.

I’ll conclude with a caveat. I didn’t check the Get Location or the Serialization code as it wasn’t needed for me to get the application up and running, but it looks okay at the moment since my element are positioned correctly and everything is serializing / deserializing. Then again, I don’t have any unit tests.

Check out the review here: http://encosia.com/2008/09/03/review-advanced-aspnet-ajax-server-controls/ and while you’re there check out some of Dave’s extremely useful blog entries on ASP.NET, JavaScript, and other topics.

Thx again Dave for the nice review.

The Story

A story of despair. Here’s how my evening went.

Act I Scene I: I just downloaded and installed the Visual Studio 2008 SP1 / 3.5 SP1 and I’m excited to take a look at how to use the Script Combining mechanism. I’ve been using the ToolScriptManager’s script combining ability for a while now, and while it is okay, it has its quirks and I was hoping the one in .NET 3.5 SP1 would be better.

Act I Scene II: I notice that the ScriptManager has a new templated section called CompositeScript. This is the spot I need to investigate closer.

Act II Scene I: I go to one of my trusty controls (AirlinesMiles.cs from my Client Event Pool example) and start to poke around at how I’m going to get the control’s script files to be part of the composite script.

Act II Scene II: Hmmm… where’s the method call on the ScriptManager object to register my ScriptReference with the CompositeScript template? Wait, I can’t find one. What the?

Shouldn’t there be something like this…

public IEnumerable<ScriptReference> GetScriptReferences()
{
    ScriptReference sr = new ScriptReference("ControlLib.UserMileageInput.js", typeof(UserMileageInput).Assembly.FullName); ;
    sr.RegisterAsCompositeScript = true;
    yield return sr;
}

or something like this…

protected override void OnPreRender(EventArgs e)
{
    base.OnPreRender(e);
    bool registerAsCompositeScriptControl = true;
    ScriptManager.GetCurrent(this.Page).RegisterScriptControl<UserMileageInput>(this, registerAsCompositeScriptControl);
}

but no, there isn’t anything like that.

Act II Scene III: @#$3234%%$@ #$@ @#$!

Act III Scene I: Really …… really?? There’s no built in way for my control to at least ask to be registered with the ScriptManager as a part of the composite script?

Act III Scene II: Despair.

Okay, I’m feeling a bit dramatic tonight, but I’m at least a little annoyed for feeling a bit overlooked as a control developer.

I get that MSFT probably had a discussion internally about whether to allow controls to register as a composite script or not and that its obvious that the feature didn’t make it. Maybe they don’t see it as part of the control developer’s UX, but only the page developer’s UX. I don’t know. Maybe their idea is to have us pull out the ScriptReferences of every single embedded JS file that could possible be loaded by any control and place them into the CompositeScript template? I’m not really sure what MSFT’s work-around plan is or why the ScriptControlManager wasn’t updated to support this ability in the first place, but I’ve got one that at least on the surface works. I shouldn’t have to though. I should be able to register my scripts as normal as I have for the past 3+ years.

Workaround

So I’ve come up with a little hacky work around for this problem for now and we’ll see where it takes me…

protected override void OnPreRender(EventArgs e)
{
      base.OnPreRender(e);
      ScriptReference sr = new ScriptReference("ControlLib.UserMileageInput.js", typeof(UserMileageInput).Assembly.FullName);
      sr.NotifyScriptLoaded = false;
      ScriptManager.GetCurrent(this.Page).CompositeScript.Scripts.Add(sr);
      ScriptManager.GetCurrent(this.Page).RegisterScriptControl<UserMileageInput>(this);
}

public IEnumerable<ScriptReference> GetScriptReferences()
{
    return null;
}

Pretty much I’ve moved the ScriptReference registration from the GetScriptReferences method to the OnPreRender method. This works in my little example, but I’ve yet to test it on a larger application.

Closing

Finally, for those MSFT folkd who every once in a while peruse my blog, please comment and explain why this turned out this way or if I missed something please let me know. I’m trying to hold back too much judgement until I hear from you.