AJAX

JavaScript for the masses

Jay Kimble — Thu, 03 Sep 2009 17:43:57 GMT

As you may be aware Scott Hanselman’s 2009 Ultimate Developer and Power Users Tool List for Windows came out yesterday. If you are like me you end up pooling through the list especially the new stuff to see if there is something cool that somehow you missed.

I found an item on the list that answers something I think I have been looking for (but not for me), but before I go on I need to give you some background (as usual).

Kevin D. Wolf (aka ByteMaster) and I have been talking over the last several months on all things Ajax. We’re both pretty deep on the topic of Ajax (Actually Kevin is deep on a number of topics), and we’re both pretty opinionated about a few things (I know you are shocked that I would say that about myself).

One of the things I’ve sort of been looking for is something that makes it easy for someone to write Ajax. The new Blend Skecthflow stuff is a HUGE game changer, but if what I want to write is Ajax then after using Sketchflow I’m back to the drawing board.

Interractions in Ajax.. found!

So yesterday, I was browsing the Hanselman list and I found a side reference to a tool to watch called “IxEdit.” All I can say is WOW! [Personal Note: Diane Leeper download this now! I think you could have some fin with this…] Their video tells it all, but I will tell you what I think is cool about it.

You create a page and add references to jquery, jquery ui, and their ixEdit script as well as a few CSS. Once you do this the page launches with a movable dialog. This new dialog let’s you create Ajax/Web 2.0 (more the latter) interactions with your page all by simply playing in their GUI. Really, really cool! Now they don’t do everything, and in fact from what I saw of the tool you can’t set up to make calls back to the server (but I could see something like that being set up, and am starting to think about it). Once you are satisfied you can “save and reload” which reloads the page and applies your designed interaction (so now you can see how it worked).. something not look right simply edit the interaction to tweak it’s setting.

When you are done it will help you deploy the script, so now you have designed JS code with out actually writing a line of code! Really, really cool, IMO!

[I spent a couple of hours looking for pictures to fancy this up a little.. I run a UI/UX users group for crying out loud.. I need to get better at that, so sorry my post is bland.. I’ll try to follow up with something more graphically pleasing]

jQuery-UI visual studio intellisense (vsdoc) file

Jay Kimble — Mon, 20 Jul 2009 13:19:18 GMT

If you’ve ever tried to use jQuery UI with Visual Studio, you’ve run into a JavaScript parse error and you lose JavaScript intellisense in Visual Studio. I wasn’t exactly sure of the issue until I read someone’s advice (who was just trying to get the datepicker working) to simply include a dummy jquery-datepicker-vsdoc.js file. So I did this for the jquery-ui.js file and lo and behold, no JavaScript parsing errors, and I had intellisense for everything EXCEPT jQuery UI.

Anyway, I dug around and couldn’t find one… so I created the beginnings of one. What you get is very core level (and not an actual working file). Simply add it to your project along side your jquery-ui.js file and VS will automagically realize that when it gives you intellisense for JavaScript and you are using (or have referenced) the jquery-ui file.

As I said it’s not complete. The areas that I know for sure is that it doesn’t give you any of the theming support.. actually the jquery.ui object is pretty much not there at all… I did get the effects and all the base controls intellisense working (datepicker, tabs, dialogs, etc.). It’s not perfect, but it will be a good start for someone else…

How to Use it
So to use this simply add it alongside your jquery-ui.js file in visual studio and visual studio should pick up my file and use it to give you intellisense. If you are using an external JS file you’ll need to use “/// <reference… /> to reference the JS file.

If I get around to it I will publish an update in the future.

File Attachment: jquery-ui-vsdoc.js

Better JavaScript class generation

Jay Kimble — Wed, 24 Jun 2009 21:15:32 GMT

For years, I have been espousing how great Script# is. I often do an advanced MS ASP.NET Ajax client talk and end it with a Script# talk. Mainly because I think that the idea of learning the nuances of JavaScript OO techniques can be a little confusing. It’s really the challenge (All you need to do is search the archives of my blog and you’ll see my own confusion on this topic).

I think many web developers can wrap their heads around building the functionality, but making something private/public/static can get a little confusing. Especially if you are used to using something like C# or VB to do it.

Kevin “ByteMaster” Wolf and I have been talking about this. As a result of those talks I started playing with an idea of allowing developers create something that feels more like OO… Anyway, I have come up with a very alpha version.

A Better OO For JavaScript??

compileClasses({    

    testClass: {        

        ctor: function() {            

            // this is a test        

        },        

        private: {            

            privateVar:1,            

            privateMethd:function() {                

                // test method            

            }        

        },        

        public:{            

            // public stuff here            

            publicVar:"2"        

        },        

        static:{            

            //public statics            

            staticVar:"test"        

        }    

    },    

    testClass2: {        

        ctor: testFunc,        

        private: {            

            privateVar2:"2"        

        },        

        public:{            

            publicMethod:function() {                

                return true;            

            },            

            myVar:"this is a test",            

            dispose:function() {            

            }        

        },        

        implements:["Sys.IDisposable"]    

    }

});

Two classes are defined here.. the first one is the testClass. you will see that I’m creating a JSON object that has members called “ctor” (constructor), “private” (private members are contained within this object), “public” (public members are contained within this object),”static” (static public members are contained within this object), and “implements” (“array of interfaces that are implemented). I also will handle single inheritance using a member called “inherits.”

I think this makes class definition a little more straightforward for those of us who aren’t closure gurus, and it just might replace the pull of Script# on my life.

Right now this all works with a simple function that uses the MS Ajax Client framework. I’m considering doing this for other frameworks (so if you love some other framework, never fear I’m considering your framework as well).

I created a codeplex project which contains a single release that contains a simple ASP.NET project (could have been a simple html page too).. Don’t fret I expect the code to be a ton cleaner in the next version (I’m reading the MEAP version of John Resig’s Secrets of the JavaScript Ninja (and am learning a ton!)

Here’s the link: JsClassDef Project

Let me know what you think.. does it stink? is it cool? I know it ain’t Resig-like, but both Kevin and I think the simplified structure is nice and not un-JavaScript-like

The two ways one writes JavaScript code..

Jay Kimble — Tue, 21 Apr 2009 15:44:54 GMT

I think sometimes in the past I have been guilty in my presentation on JavaScript (JS) of not defining for myself who my audience is. Actually I know that I’ve done a poor job of this. You see there are 2 ways to write JavaScript code. Something that I knew, but recently realized the importance of.

OO Baby
If you are building your own controls then you are all about building things in an OO manner because it helps you in the areas on manageability. You may or may not be testing your components with automated/unit test tools and quality is everything.. as well as browser compatibility. When doing this one of the major struggles in your world will probably be in the area of memory leaks (I’ve joined the coalition to kill IE6).

To be honest this is probably not you, but if you’ve come to one of my deep JS talks… this is my target (and my cardinal sin… sorry)

The way you probably use JS
Ok, the most common use of JS and the way that I think most people use it is to do minimal coding to wire up some validation or to wire up some interaction or even to include some Web 2.0 control (aka “Ajax Control”). Your mantra is “I want to get in and out quickly so that I don’t have to touch JS more than I need to…" We usually don’t take the time to test this stuff because it feels more declarative and that seems trustworthy (although you could test it)

This is exactly why jQuery is so popular. Not only does encourage this type of thinking (and even embraces it), but the re-usable plugins take on this same sort of thinking (the show/hide methods come to mind). That and the sheer fluency of the library makes it easy to use. The selectors are really a variation of the same selectors that CSS uses so you are re-using knowledge that should already be in your head as a web-developer/designer..

Anyway, while JS OO is cool.. most of us work the other way (and even those of us who use JS OO do most of our JS coding using the latter method)

CodeRush/Refactor Pro refactors Javascript too

Jay Kimble — Wed, 18 Feb 2009 15:05:29 GMT

I just saw an article talking about a new Ruby product from JetBrains. One of the side effects of this product is that they offer refactoring support for JS code. <yawn />

I had to chuckle a bit. I guess my love affair with the Developer Express’ Code Rush/Refactor Pro (CR/RP) addin continues to pay off… I’ve had refactorings for JavaScript AND HTML/ASP.NET markup for about a year (and they added it a long time ago). If you didn’t know that… now you do (they keep finding new places to add refactorings… it seems like nearly every file in your project is fair game with their addin.)

The more I work with CR/RP the more I love it. I keep finding new things I can do with it. Their most recent version actually contains a feature that I missed from ReSharper (code analysis… they will make code improvement suggestions and can auto-implement it).

There’s also a new community addin that builds some test runner facilities within the IDE (although not as mature as ReSharpers).

One thing to remember though… with CR/RP you need to somewhat relearn to use your IDE and you need to tame their addin a little for your own purposes… going through their training videos is a must (unlike ReSharper). At the end of it you will be MORE productive with CR/RP (although it’s debatable whether you would be more productive with it over ReSharper… it’s a preference thing.. I personally think I am more productive though).

[NOTE: I don’t work for DevExpress and they don’t pay me to do this… in fact I’m currently out of date on my product upgrades which ended in Dec. The release I’m using is from November… and it absolutely rocks]

Client-side Scripting 101 Part 2: JavaScript OOP Basics

Jay Kimble — Tue, 03 Feb 2009 21:50:02 GMT

[Sorry this took so long to get out… I have been distracted by Windows 7 and am working between 2 OS’ on 1 machine… Win7 is now my primary OS and I didn’t have this post here… that and I’m now twittering doesn’t help either]

Ok, since in the first version of my last article I referenced the "prototype" property, it felt natural to begin by talking about JavaScript OOP basics. Now, I’m not going to try to define all the terms that usually get associated with the type of OOP used in JavaScript ("JS" hereafter). I want to give you --my valued reader-- with the practical knowledge. So let’s go over how JS as a language works:

JavaScript objects and types are extensible simply through use
What this means that to add a field to a JS object you need only reference the field. As a result there are 3 states of any value that you interrogate in JS: has a value (like 2, "v2", etc), is null, is undefined. "Null" means that the type member (property, field, method) is defined, but as of yet there is no value here. "Undefined" means that a type member does not exist as of yet. So let’s illustrate this with some code:

        1: var myObj = {};

       2: myObj.myNewProperty = null;

       3: var test1 = typeof(myObj.myNewProperty) == "undefined"; // returns false

       4: var test2 = typeof(myObj.myOtherNewProperty) == "undefined"; // returns true

       5: var test3 = (myObj.myNewProperty == null); // returns true

So what did we do there? Well, we created a new object; the "{}" is short hand for "new object()." BTW, that’s really JSON syntax (there’s more to that and we’ll cover it much later in another column). After creating an empty object we create a "myNewProperty" field and set it’s value to null (this field is created and is "defined"). Next we do a couple tests on the variable. The first test checks to see if the "myNewProperty" field on the created object is undefined (it is defined so test1 is false). The next test checks to see if the "myOtherNewProperty" field on the created object is undefined (since this is the first time we referenced it, the field is in fact undefined, so test2 is true). Finally we test to see if the "myNewProperty" field on the created object is null (which it is).

JavaScript object’s members can be referenced like a dictionary
In the example above we could have referenced the "myNewProperty" field like this:

myObj["myNewProperty"] = null;

What this means that with JS we can sometimes reference object members as if they were an array or more like a HashTable in .NET. The real importance of this is that JS objects are really strange characters in that they can be manipulated like both an object and an array/dictionary/hashtable. We’ll be briefly revisiting this syntax at the end of the Prototype section (but don’t blink… it’s really fast).

Function is used to create a class
So thus far, we have extended objects and not classes. In JS we can use the Function type to define a class (I know that seems weird, but bear with me). Functions can contain other functions which have access to all the variables within them and any variable that it’s parent function can access. The constructor is actually the parent function. Let’s look at an example:

       1: function myClass()

       2: {

       3:   var privateVar = "Private variable";

       4:   this.publicVar = "public variable";

       5:   this.publicFn = function() {

       6:     // this fn can manipulate any of the above vars including the private ones

       7:     privateVar = "Private accessed by publicFn";

       8:     return "Public Function";

       9:   }

      10: }

myClass is a class that has a single private variable called “privateVar”. It has 1 public variable/field called “publicVar” and a public function called “publicFn.” We can create a variable of this type by doing the following:

       1: var myNewObject = new myClass();
  

The above example isn’t the way this is normally done though. Here’s why. That initial function/constructor looks really weird with the function declaration inside of it (imagine a public field declared after the a function declaration. It would get really messy quickly).

Prototype
So instead there is a special properties called “prototype” which can be used to add additional members to a function. Here’s an example of what that looks like:

       1: myClass = function()

       2: {

       3:     var privateVar = "Private Var";

       4:     this.publicVar = "Public Var";

       5: }

       6: myClass.prototype.publicFN = function()

       7: {

       8:     privateVar = "Private var accessed by function";

       9:     return "Public Function"

      10: }

We made a couple changes here. First we switched the order around for the function declaration. This is all perfectly legal. The function syntax creates an anonymous function and assigns it to the myClass (for instance). As you can see from the prototype syntax on line 6 that you simply extend the prototype object like we did earlier in the first code example.

We’re almost done. Let’s make a slight change to the more preferred syntax(and see our first very small example of JSON):

       1: myClass = function()

       2: {

       3:     var privateVar = "Private Var";

       4:     this.publicVar = "Public Var";

       5: }

       6: myClass.prototype = {

       7:     publicFn : function() {

       8:         privateVar = "Private Var changed by function";

       9:         return "Public Function";

      10:     },

      11:     get_PrivateVar : function() {

      12:         return privateVar;

      13:     }

      14: }

Not much has changed from the last version except one thing, and we’re setting the prototype function to an object (remember that the squiggly brackets are JSON syntax for object). The methods are mapped out using a “name:value” syntax. and is comma separated (you get a weird error if that comma is missing). We also went ahead and added one more new member which now exposes our private variable via a “property” get function.

There’s actually another variation on the syntax, but this is good enough for now. With this in hand you should be able too read just about any JavaScript object library and figure out where you can call things.

You might also notice that inheritance doesn’t look like it’s baked in… which is absolutely correct! Inheritance is not baked in. You have to use a separate framework to get it (it shouldn’t be that hard to see how one would get inheritance. One way would be to simply query the Parent type’s prototype and add those methods/properties to the child class; we can do all this by using that dictionary/HashTable syntax we mentioned above and a foreach loop. There are other ways as well but that is way beyond the scope of this tutorial --and really isn’t something you should care all that much about right now).

After all, being able to read this syntax was our overall goal (we want to use Script# to actually do our programming).

Next time we’ll cover Script# basics. (I’ll try not to take 3 weeks to get you the next installment)

Client-side Scripting 101 Part 1: The Reasons

Jay Kimble — Sat, 03 Jan 2009 03:13:43 GMT

[Welcome to my multi-part tutorial on. I know I did an introduction earlier in the month, but before we dig in deep into this I thought it would be good to get a few questions out of the way.]

Why is this (Client-side Scripting) all that important to me?
You may be thinking "Hey Jay, my company bought Telerik/Component Arts/Component One/{fill in some other ASP.NET tools suite} and it seems to do everything I need and more. I can see some places where a little client-side code is helpful, but it’s not that important, is it?"

Well, I’m definitely not one to criticize the third party tools vendors, but their tools are just that tools. If your site grows large enough you will run into a place where you need to tweak their tools, and my experience is that all the ones I’ve mentioned have really nice client-side APIs that underlie their server-side components. Stuff that will really let you push the envelope of their tools. But, you probably already know that. The hard part is for all the great things these tools can do, sometimes you need something else (usually a little more light weight). In order to do this you need a background in client-side technologies so that you are able to assess your solutions.

For instance, in my day job I created an MS Ajax behavior that takes a regular HTML table and adds a selection behavior. We did this to replace the big name grid we are using because, while this grid does amazing things, it also comes with a price of a heavy footprint and a larger than desired viewstate (we’re trying to slim our pages for performance sake). I also have created 2 additional behaviors: one injects client-side paging to a regular HTML table, and the other provides sorting functionality via the column header row. All of these behaviors inherit from a common class that wraps the table. My lightweight behaviors are simple components that can handle up to about 1000 rows which make them really useful for smaller sets of data. I tried them on as many as 5000 rows which gave OK but sluggish performance, and with 10,000 rows was simply unusable (I was using all three components, so it might be possible to use say just the paging and get decent performance).

It comes in handy to be able to build these types of lightweight components (which incidentally only took me about 40 hours to build all 3 which included server-side extenders).

Our first term: Client-side (or Ajax) Behavior
Since I have thrown the term "behavior" out a couple of times, let’s go ahead and define what it is exactly. In the realm of MS Ajax (and other frameworks), a client-side behavior is a client-side component/class that injects functionality into an HTML element. In MS Ajax, it is a separate component that is associated with an HTML element. When activated, it usually sets up UI events (onclick, onfocus, etc.) to intercept some UI interaction and apply new interactions. It can also inject additional css classes/styles or html elements on the page to apply a particular look (which is what the Ajax Control Toolbox’s Drop Shadow and the Rounded Corners behaviors do). It all depends on what the component needs to do. If you have played with any MS Ajax toolbox on the server side, you have probably throw Ajax Extender controls on a form; extenders are a server-side wrapper for the client behaviors. I hope that’s clear. If not fire off some comments to me at the bottom of this post and I’ll try to better explain in the comments (and will update this accordingly).

One of my goals for this blog series is to take you from knowing a little bit about client-scripting (and maybe nothing) to being able to build your own behaviors and extenders.

JavaScript is like a foreign language to me... Why couldn’t this be easier?
This may shock you, but I struggle with it too -- and I’m a(n admittedly) self-proclaimed guru with it. Two weeks ago (I was off last week) I wrote a very simple JavaScript component/class and I forgot something. I set up a timer event and it wasn’t making the call correctly into my class. Eventually I realized that what was happening was that I was calling a method within my JavaScript class and the instance of that class was being lost. I needed to use the MS Ajax "Function.createDelegate" function to get a wrapper function that wouldn’t lose the instance of my class. This is a total pain in the you-know-where. I actually told my boss that this is the exact reason I use Script# since it takes care of this stuff for me.

What the Heck is Script#?
Script# is a life saver! It is the invention of Nikhil Kothari (MS Ajax Architect and SilverLight2 Architect, and he is one of my heroes... I hope I get to meet him at Mix09). What it does is let you write C# code in Visual Studio against a framework (either Nikhil’s or MS Ajax... there are also jQuery extensions and a few others for it as well). This framework has a set of CoreLib replacements (System, etc.) that consist of set of .NET dlls and a set of JS client libraries. When you compile this code, you get a DLL which can be used in other Script# projects (yes, there are VS templates for creating a new Script# project), and a set of JS files (debug and shrunk runtime versions). Script# makes it easy to create multiple inherited classes (an object tree if you will) as well as it handles things like passing functions around.

So that means I don’t have to know anything about JS right? Cool!
Hang on there! You will need to know a little bit about this stuff as it will help you read the code generated by JS. You can always patch bugs with Script#, but testing will (at this time) always exist in the JS side (in a browser), so you need to know enough to get around the source code that gets generated. The line numbers will always point to a line in the generated JavaScript (for instance), so your going to need to be able to read the JavaScript file and determine where the problems exist (you can still fix the code in your C# code, and can write debug messages that show up in the JavaScript console (or in VS if you are debugging the script running in IE).

So next up will be a column on JS OOP Basics.

C# Style Attributes in Script#/Javascript

Jay Kimble — Sun, 21 Dec 2008 04:19:03 GMT

[If you aren’t knee deep into Script# or JavaScript this post might not make any sense. If you are into BDD (or TDD) you might want to read further to see some ideas I’m playing with. If you write TDD tools for running tests... please read further... ]

[NOTE (For Joe Only): Joe, yes, this is a "shiny stuff" post; some day it might have a practical use at which point I’ll write a non-alpha geek version of this post which will be a tutorial of how to use this to make your life easier.]

One of the things I’ve been looking for again is a way to create C#-Style (or even Java-Style) attributes on a function in JavaScript. Mind you, I’m the author of such a library, but making it work in Script# is a bit of a pain. To do it would require me writing in Script# something like this (and I’ll give away what I want to do as well):

// NOTE: what follows is something I could do not something that is fully working
// the JS Style Attributes work and that is all
  
[Concern()]
public myClass
{
    public myClass()
    {
        Script.Literal("/*--@Concern()--*/");
    }
  
    [Observation("When adding a person, full name should not be blank")]
    public void When_adding_a_person_full_name_should_not_be_blank()
    {
        Script.Literal("/*--@Concern("When adding a person, full name should not be blank")--*/");
        // Test Code appears here
    }
}

See that Script.Literal in the constructor? That’s required for my JS Attributes Library and for Script#. You see we have to force a comment into Script#, and do it in a manner that the comment ends up in the runtime version (non-debug version) of the code.

So why would I want to use regular attributes as well ("they don’t make their way into the JS code, right?"). Well, since my BDD experimentation is starting to be seen. I’ve started experimenting using Test Driven.Net with Script# assemblies (I took a Bertrand Le Roy’s Simple Test framework for JavaScript and converted it to Script# (I also made a couple enhancements, so I could target alternate consoles... instead of just html). After hooking everything up, I ran the DLL through reflector and sure enough, it decompiled into my exact source code. Next I tried running it with Test Driven.Net personal with no luck... not sure what I need to do to get it running actually, but I bet if I had a Test Attribute that would start sending me in the right direction.

Regardless, I’m not all that interested in regular xUnit style frameworks; I really want BDD. One of the things I started doing was investigating all the BDD style frameworks for .NET. Almost all of them inherit from NUnit, so if I wanted to say port Scott Bellware’s SpecUnit to JavaScript/Script#, then I would need to have an NUnit implementation and a recent one. Recent NUnit implementations all use Attributes which is how we get here. [For the acronym police: BDD stands for Behavior Driven Development... I won’t attempt to define it as I would probably get it wrong, but it’s a variation on Test Driven Development -- TDD... BDD emphasizes testing specs, user stories, use cases, etc.]

BDD with JavaScript
One of the things I’ve been thinking about is how something like Script# DLLs lend themselves for testing. Seriously. If you take an UI behavior approach to components, then you need to isolate the functionality by creating a fake element (or more than one), attach the behavior and then start firing events on the model to make sure that the desired results happen. For instance if I have a draggable element then I want to make sure that the element shows the hand cursor when the mouse passes over the element as well as when the mouse button is down and the mouse is moved does the element’s position changes, etc. I keep thinking that this should be infinitely easier in the DLL as an abstraction then in the actual browser. Of course one needs to test various browsers, but if your math is off for instance, it won’t matter which browser you use.

Why BDD and not TDD? Well, I usually have a list of rules that the UI Behavior should adhere to before I ever write a line of code. This is a perfect fit for a BDD style of test first (and yes, I want to do BDD testing first... I know that’s shocking, but I do want to try it... for how I TRY to build JS components quality is usually a huge factor that BDD would greatly help).

Script# - Literal feature... How did I miss this one?

Jay Kimble — Wed, 10 Dec 2008 20:41:29 GMT

Today, I’m doing some work with Script# and I ran into the one thing about Script# that I don’t like: there are a few areas where Script# just isn’t able to perform some task. This happens a lot when you are developing Atlas (MS Ajax) components instead of using Nikhil’s ScriptFX client library.

Today I ran into one of those areas. Specifically I needed to dynamically add/remove options from a select element. In JS this is a breeze for me, but Script#'s SelectElement’s options array is defined as a dictionary which doesn’t allow for adding elements. In the process of doing it I ran across an article on how to do it in a more DOM-compliant manner (read that as "the standard way you’re supposed to do it"). The article is over here.

Anyway, I originally used Script.Eval, but I knew that was going to put some ugly code in my resulting Javascript files (I really do hate that).

While I was doing that I noticed the reference to "Script.Literal" in my intellisense, so I grabbed the docs and took a look. To my amazement this new element did away with this limitation once and for all.

Here’s what it does. It lets you emit your own script code into the resulting script. So I could use the above article and reference properties that don’t exist in the Script# implementation. That really rocks!

So you could do something like this:

// Hide all elements of a certain type in my doc and hide them

// (this is a contrived example, I know)

public void HideAllElementsOfType(string tagName)

   Script.Literal("$(tagName).css('display', 'none')"); // this is a JQuery call

In the resulting JS there will be something like this (I’m manually doing this so it won’t be exact here):

function hideAllElementsOfType(tagName)

    $(tagName).css('display', 'none');

You see? it took the string in the literal and injected it into the source. Using a "$" is not possible with Script#/C#, but we were able to inject it into our code with no problems. Literal also supports String.Format syntax as well. This is so cool! It means that it is trivial to get around Script# limitations and still get good performance (no need to litter your code with Eval)

Tampa Code Camp 2008 Wrap up

Jay Kimble — Sun, 07 Dec 2008 20:36:53 GMT

Yesterday I had an excellent day at the Tampa Code Camp. My wife gave me a vacation day from the family (thank you!) which makes for a good day that I can just hang out catch a couple sessions, speak, and connect with a few other geeks.

I have attached my slides and sample projects to this post (the sample solution requires that you have Script# installed). I also attached my MS Ajax Cheat sheets as well.

Normally that would be all that I would put up here, but there were some additional things that happened as a result of me meeting a few people. BTW, I absolutely love Code Camps, but usually not for the presentations. I normally end up meeting a couple people that I have a really cool conversation with. In this case I had a little chat one of my attendees that got me thinking. Morgan mentioned that she would love to see me do something that would help someone like her wrap her head around all this client scripting stuff (she’s an experience Windows Developer whose now having to build some web sites and is starting to see the need to be able to dive deeper than throwing an UpdatePanel on a form.

She got me thinking about doing what I’ve started thinking of as "Dive Deep" into ClientScript. I wanted to do another Day of Ajax (but I think Joe is a little hesitant to let me do it as in the past I have tended to dive just below the stuff I’m currently doing losing most of the people in the room... actually my talk yesterday was probably another one of those... sorry, if you were one of those people...) Actually Joe wasn’t the only one who kind of shot me down, so an event sounds out of the question.

New Blog post series (for Morgan and folks like her)
Since I can’t do another Day of Ajax (well, I could if someone wanted to give me a facility to do it in...), I’ve started thinking about doing a series of blog posts to help someone go from minimal knowledge (I can drop a control on a WebForm) to being able to customize a behavior/extender in the Ajax Control Toolbox and to be able to build your own controls. These skills really go outside your core MS skills... you need to be able to look at things a little differently. These blog posts will have source code in JavaScript and in Script# (since I imagine a lot of people doing ASP.NET would rather leverage a skill that they use on a regular basis). We’ll be leveraging both the MS Ajax ClientScript library and the jQuery library.

I’ll try to get some of this going this week and will try to regularly blog about it.... with the holidays please forgive me if I fall behind.

I was right BDD is cool and translates to my world really well
I also had some conversations with Sean Chambers and Chris Bennage. Between conversations I have had with Chad Myers and Sean, I have a decent agile community in Los Techies who seem to be less thick skinned and are really good at communicating their methodology in a very clear manner without being zealots. My conversations with Chirs really showed me the practicality of the whole discipline (looking forward to having more conversations with Y’all). I actually attended Sean’s BDD talk and found it really enlightening... I’m looking for a good project to try BDD on (and BDD first). If I can manage to not tick off Mr. Reynolds, maybe I can find some Agile friends in Florida that I can pick a few things up from (I leave it all open ended at that).

So you’ll probably hear some posts around this subject as well. I actually had Chris admit that he over-architected a sample once (which has probably been my problem with some of this stuff... FWIW, all my conversations about DI seem fairly stupid at the moment as what I build typically is DI in some form or another). Anyway, BDD is something I’ll definitely be exploring a little more (since I was given a copy of TypeMock, I’ll be exploring that was well).

Summary
All in all a really great day for me.

Here’s the files Slides

Sample Solution

Jay’s MS Ajax Cheat Sheets