Performative Sleep

I was busy writing away in a notebook last night when I suddenly realized that I was sleeping.  In the dream, I had been working on a commentary on Montaigne’s essay Of Cannibals.  The problem with discussing dreams, of course, is that it ofen leads one into an embarrassing consideration of one’s own inner life which tends to be self-stroking and not particularly revealing — or rather, it reveals some self-absorbed aspects of one’s own personality even as one is sure that it is revealing some great inner-truth, like John Marcher’s beast in the jungle.  Or even worse, it is like taking one of those IQ tests that occassionally pop-up in one’s browser and determining from it that one is quite intelligent.

When I woke up in the morning, there was no commentary written out at my bedside, or even prepared in my head.  I don’t even remember what I was trying to say about Of Cannibals.  This contrasts starkly with the experience of sleep coding, which occassionally overcomes software developers who have been working too hard on a particular problem, and in some circles is even considered to be a mark of particularly virtuous coding.

I am convinced, as many programmers are, that sleep coding really works — that is, that in sleep, programmers actually solve problems from their waking hours.  I have often spent hours on a particularly insidious problem only to find, after a good night’s sleep, that I am able to quickly fix the problem the next morning.  And it seems to be something different from simply taking a break.  Walking away from a problem for a few hours, while it can be helpful in reducing stress, has never had the revelatory effect that sleeping has had.  I’ve even come to the point that when I consider a problem to be particularly difficult, instead of trying to solve the problem right away, I plan on learning as much as I can about it in order to hand it over to my dream-coder to solve in the night.  I think of this as an occult offshoring.

It is quite possible, of course, that the experience of dreaming code and the phenomenon of having code solved in one’s sleep are two entirely different things.  The second can be true even if the first is essentially meaningless, a phantom caused by neurons misfiring in our sleep.  And this is, in some cases, the solution to the mind-body problem.  The theory goes that when awake, we are merely observers of a mechanistic process with epiphenomenal experiences that do not actually affect what is going on in the world.  We are merely passive observers, even though we think we are actually participating and making decisions — though this implies a rather inelegant duplication of entities in the world.  Why should it be that I can code in my sleep, and also observe myself coding in my sleep through my dreams, but these two things are not the same thing?

And also, is this something that only happens for computer programmers?  Is it the case that our bodies can perform high cognitive functions without us, but only for certain types of tasks?  I don’t recall ever waking up in college with an essay fully formed in my mind.  Then again, we are told that Coleridge woke up from a dream with Kubla Kahn fully formed in his mind, and only after being interrupted by a visitor and taking a break from it, did he lose it again.

II. Imperative Drag Drop

 

To accomplish the same thing using a programmatic model requires a bit more code, but not much more. It is important to understand that when you add an Atlas Script Manager component to your page, you are actually giving instructions to have the Atlas JavaScript library loaded into your page. The Atlas library, among other things, provides client-side classes that extend the DOM, and provide you with tools that allow you to code in a browser agnostic manner (though there currently are still issues with Safari compatibility). These client-side classes also allow you to add behaviors to your HTML elements.

To switch to an imperative model, you will need to replace the XML markup with two JavaScript functions. The first one is a generic script to add floating behavior to an HTML element. It leverages the Atlas client-side classes to accomplish this:

<script type="text/javascript">
function addFloatingBehavior(ctrl, ctrlHandle){
    //create new floating behavior object
    var floatingBehavior = new Sys.UI.FloatingBehavior();
    //floating behavior class has a Handle property
    floatingBehavior.set_handle(ctrlHandle);
    //convert object reference to Atlas client control
    var dragItem = new Sys.UI.Control(ctrl);
    //get behaviors collection from Atlas control 
    //and add our floating behavior
    dragItem.get_behaviors().add(floatingBehavior);
    //run the floating behavior's internal javascript
    floatingBehavior.initialize();
}
</script>

The function takes two parameter values: the HTML element that you want to make draggable, and the HTML element that is the drag handle for the dragging behavior. Next, you instantiate a new Atlas client-side behavior object. The floating behavior has a property called “handle“, to which you pass the handle HTML element. You then need to create a new client-side control object based on the control you want to make draggable. Turning your div tag into an Atlas client-side control enables you to add Atlas behaviors to it. You use the “get_behaviors()” method to return a collection of behaviors, and the add method to add a new behavior to your HTML object. Finally, you call the “initialize()" method of the behavior object to allow the behavior to configure itself internally. This utility function will be used throughout the rest of this tutorial.

Now, you need to call the “addFloatingBehavior” function when the page loads. This, surprisingly, was the hardest part about coding this example. The Script Manager doesn’t simply create a reference to the Atlas JavaScript libraries, and I have read speculation that it actually loads the library scripts into the DOM. In any case, what this means is that the libraries get loaded only after everything else on the page is loaded. The problem for us, then, is that there is no standard way to make our code that adds the floating behavior run after the libraries are loaded; and if we try to run it before the libraries are loaded, we simply generate JavaScript errors, since all of the Atlas methods we call can’t be found.

There are actually a few workarounds for this, but the easiest one is to use a custom Atlas event called “pageLoad()” that actually only gets called after the libraries are loaded. To add the floating behavior to your div tag, when the page is first loaded (but after the library scripts are loaded), you just need to write the following:

<script type="text/javascript">
    function pageLoad(){
        addFloatingBehavior(document.getElementById('draggableDiv'), 
                            document.getElementById('handleBar'));
    }
</script>

which, in turn, can be written this way, using an Atlas script shorthand that replaces “document.getElementById()” with “$()”:

<script type="text/javascript">
    function pageLoad(){
        addFloatingBehavior($('draggableDiv'),$('handleBar'));
    }
</script>

And once again, you have a draggable div that behaves exactly the same as the draggable div you wrote using the declarative model.

I. Declarative Drag Drop

The first task is to use Atlas markup to add drag-drop behavior to a div tag. By drag and drop, I just mean the ability to drag an object and the have it stay wherever you place it. The more complicated behavior of making an object actually do something when it is dropped on a specified drop target will be addressed later in this tutorial. To configure your webpage to use Atlas, you will need to download the Microsoft.Web.Atlas.dll file from the Microsoft site into your bin folder and configure your web.config file with the following entry:


<system.web>
<pages>
<controls>
<add namespace=”Microsoft.Web.UI”
assembly=”Microsoft.Web.Atlas” tagPrefix=”atlas”/>
<add namespace=”Microsoft.Web.UI.Controls”
assembly=”Microsoft.Web.Atlas” tagPrefix=”atlas”/>
</controls>
</pages>
</system.web>

You will need to add an Atlas Script Manager control to your .aspx page and configure it to use the AtlasUIDragDrop library file:


<atlas:ScriptManager ID=”ScriptManager1″ runat=”server”>
<Scripts>
<atlas:ScriptReference ScriptName=”AtlasUIDragDrop” />
</Scripts>
</atlas:ScriptManager>

Add the div object you want to make draggable, and make sure it has a drag handle:


<div style=”background-color:Red;height:800px;width:600px;”>
<div id=”draggableDiv”
style=”height:100px;width:100px;background-color:Blue;”>
<div id=”handleBar”
style=”height:20px;width:auto;background-color:Green;”>
</div>
</div>
</div>

Finally, add the markup script that will make your div draggable:


<script type=”text/xml-script”>
    <page xmlns:script=”http://schemas.microsoft.com/xml-script/2005″>
        <components>
            <control id=”draggableDiv”>
                <behaviors>
                    <floatingBehavior handle=”handleBar”/>
                </behaviors>
            </control>
        </components>
    </page>
</script>

And with that, you should have a draggable div tag. The example demonstrates the simplicity and ease of using the declarative model with Atlas. In the terminology being introduced with Atlas, you have just used declarative markup to add floating behavior to an HTML element.