MS Ajax

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

Using the Ajax control toolbox with jQuery (and ASP.NET MVC)

Jay Kimble — Wed, 10 Jun 2009 02:19:30 GMT

[Here’s a preview of something I’m going to show Thursday night at the Tampa MVC group.]

You may have thought that by jumping on ASP.NET MVC that you have to leave behind all the cool Ajax Control Toolbox controls.. or more than likely you realize that it’s possible to use them, but one has to be a “JavaScript Rocket Scientist” to use them..

It’s really not, but you do need a couple things to use them.. First of all go here (Bertrand Le Roy’s blog) and pick up the jQuery plugin that let’s you instantiate MS Ajax Behaviors. Next go here to the Ajax Control Toolbox project and get both the ScriptFilesOnly project and the Source code as with MVC you won’t need anything but the JS files since the source/DLLs are for WebForms-related controls, but the Source code contains the debug version of the JS files which we’ll need (By the way, 6 months from now that link to the Ajax Control Toolbox will be old so you’ll probably want to get the latest release, and not the release I pointed at).

Now let’s look at how you would wire up the DropShadow behavior (aka the DropShadow Extender). First of all, we need to figure out the references. Thanks to Visual Studio 2008, this is easy. Using the text editor/view of your choice, open up the DropShadowBehavior.Debug.js from the Source project (not the ScriptOnly zip); this is located under the zip file at .\AjaxControlToolkitSource\AjaxControlToolkit\DropShadow. When you open up the file you will see the following at the top of the file:

/// <reference name="MicrosoftAjax.debug.js" />

/// <reference name="MicrosoftAjaxTimer.debug.js" />

/// <reference name="MicrosoftAjaxWebForms.debug.js" />

/// <reference path="../ExtenderBase/BaseScripts.js" />

/// <reference path="../Common/Common.js" />

/// <reference path="../RoundedCorners/RoundedCornersBehavior.js" />

/// <reference path="../Compat/Timer/Timer.js" />

The first 3 items are all the standard MS Ajax client library, so we’ll need to reference those. Now we need to look at the last 4 items. If you open up the files from the ScriptOnly zip file, you aren’t going to find these exact named files; to find the right file look at the end of the file name to find the actual file you need to reference. You’ll also need to reference jQuery and Bertrand Le Roy plugins. Here’s what the references look like:

<script src="Scripts/MicrosoftAjax.js" type="text/javascript"></script>

<script src="Scripts/jquery-1.3.2.js" type="text/javascript"></script>

<script src="Scripts/JqueryPlugin/jquery.MicrosoftAjax.js" type="text/javascript"></script>

  

<script src="Scripts/MicrosoftAjaxTimer.js" type="text/javascript"></script>    

<script src="Scripts/MicrosoftAjaxWebForms.js" type="text/javascript"></script>    

<script src="Scripts/AjaxCT/AjaxControlToolkit.ExtenderBase.BaseScripts.js" type="text/javascript"></script>

<script src="Scripts/AjaxCT/AjaxControlToolkit.Common.Common.js" type="text/javascript"></script>

<script src="Scripts/AjaxCT/AjaxControlToolkit.RoundedCorners.RoundedCornersBehavior.js" type="text/javascript"></script>

<script src="Scripts/AjaxCT/AjaxControlToolkit.Compat.Timer.Timer.js" type="text/javascript"></script>

<script src="Scripts/AjaxCT/AjaxControlToolkit.DropShadow.DropShadowBehavior.js" type="text/javascript"></script>

Here’s how we can then make every div with a “box” class to have a drop shadow:

$().ready(function() {

    $(".box").create(AjaxControlToolkit.DropShadowBehavior,

            { 

                Opacity: 0.3,

                Rounded: false,

                TrackPosition: true,

                Width: 5

            });

});

See that JSON string (lines 3-8). If you look at those settings closely and compare them to the Ajax Control Toolbox documentation web site, you’ll see that these are the same settings that the extender uses which should make everything easy.

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.

PDC2008: Reactions to ASP.NET 4.0 upcoming features presentation

Jay Kimble — Thu, 30 Oct 2008 16:05:13 GMT

I’m listening/watching this video on Channel9 which is on the ASP.NET 4.0 preview. Scott Hunter is the main presenter (at least at the beginning). This will probably be a little different of a post by me...

Web Forms

Did he say "HTML Standards Compliant?" (cool!)
ClientIDs will be controlled by us (no more mangling... Hurray!)
Moving away from table-based controls and using CSS2 adapters (sort of... invisibly)
URL Routing (yawn... We have this in SP1... It’ll probably be easier to use)
Supposedly better View-state controls (I’m dubious about this)

More granular control
Ability to turn off Viewstate on Gridview/Listview without issues

Client Script

jQuery intellisense (did he go to a Google site?)
Ajax Control Toolkit will be adopted by MS (it will be a part of ASP.NET in 4.0)

MS will support it.
MS will enhance it

Rich Client-side templating controls (I’m already embedded in this stuff)

[Wow.. Bertrand is up..]
[I wish I could see the source code... I hope they give that away]
The big thing is that JS it’s pretty easy to do and it minimizes the amount code you need to write on the client

Phil’s demo (mentioned below) reiterates that MS Ajax and jQuery work well together

ASP.NET MVC [not something I’m extremely excited about, but I am interested in it]

Hint at a auto build of pages when you point at an object... (Dynamic Data??)
Ajax in MVC with MVC

[It’s Phil Haaack...]
Phil demos Partial rendering

returning a couple items in a JSON string
[Actually in some respects Ajax can be easier in an MVC app... in any MVC app not just MS' ASP.NET MVC]
[Phil blew up his text... I can actually read it]
Next demo is sort of an UpdatePanel-like demo [simple To Do list updated without a page render by the browser]

Uses "using Ajax.BeginForm" to define the scope of the form tag [very cool IMO]
BeginForm has some options that let you define what you want to happen when the form is submitted and returns and then what you can execute something after the submit is done [in this case a background call is made and a specified DOMElement is updated and then jQuery effect is called]

ASP.NET Dynamic Data

More than Scaffolding [Not to self I need to check this out some more]

[Scott Hunter is demoing this]
Demo is a blog app [same as one of the initial Rails tutorials]
It builds a set of templates for your data model
It uses these templates for the data display/edit/etc.

Enhancing (surprise, surprise) MVC [for those who don’t know this makes ASP.NET MVC a real competitor to Rails]
Supports custom Data Layer aka Business Logic Data Source
Better filtering
Better control over column order, and columns that are shown
Dynamic Data to ADO.NET Data Services [Pronounced "Astoria"]
[Another demo to show the last 3]

Search screen [a lot of which is automated if not all... he doesn’t show how we get here... just the code that is here]
Created via LinqDataSource with a where child tag that has additional child tags defining fields to search on
Same LinqDataSource can control the visibility of fields

Dynamic Data works against IQueryable Data source : LinqDataSource (EF, LINQ to SQL, etc.), AstoriaDataSource, Business Logic DataSource (sort of like the Object DataSource except that the class is IQueryable aka usable from a LINQ query [Cool!])

Astoria DataSource which allows an Astoria service as the source of data in a server-side app [Yay!]
ASP.NET Core changes

Swap out the Cache mechanism via a provider mechanism [Yay!]
Fixes to pain points

[I skipped the questions]

Tampa UX (TUX) First Meeting Tomorrow Night (Sept. 10th, 2008)!

Jay Kimble — Tue, 09 Sep 2008 18:28:54 GMT

Since we are still waiting on the website to go live (it will be at http://www.tampaux.org once the files get copied up), here’s some detailed info on the TUX meeting tomorrow ay 6:30 (for food) with the actual meeting starting around 7:00pm (we should be done around 9:00pm)

Here’s Answers Systems (where we’re meeting) on Virtual Earth

That address is

4029 Tampa Rd, Oldsmar, FL 34677-3206.

Basically, if you are coming from Tampa, take Hillsborough Ave. to Oldsmar. We’re the bullding (on the same side of the street) just past the McDonald’s that you come to after passing RaceTrack Rd.

If you are coming from Pinellas, take 580 (or Tampa Rd) east. Look for right after 580 merges with Tampa Rd, look for the McDonald’s on the left (you can also turn at the light right after the merger with Tampa Rd. (but then you have to drive clear through the parking lot to get to our building).

Answers Systems is the building next to McDonald’s (actually it is across the little side road there... not sure of the name... the back of our building faces McDonald’s).

BTW, if you get lost my cell phone is 727.608.6453 (feel free to call me if you get lost).

PS Contest!

In case you forgot, some lucky winner will walk away with an MSDN Premium Subscription (thanks to Bill Reiss)

TUX Update... (AKA I missed something)

Jay Kimble — Thu, 04 Sep 2008 20:27:56 GMT

MSDN Premium Subscription is up for grabs

I forgot to mention this yesterday. Bill Reiss our resident MVP is giving away an MSDN Premium Subscription. So if you come you have a chance at getting it.

Multi-location

BTW, we are working toward being multi-location, so if you are in another state in the US (probably more of an East Coast thing) or in Florida, one of our goals is to make our meetings available via streaming (but only to groups... sorry you won’t be able to just dial up our stream from your desk at home)

Writing Better JS Components

Jay Kimble — Tue, 12 Aug 2008 12:04:33 GMT

Perry (my boss... a developer/manager... he codes and manages) and I have been having a recurring conversation lately. One that keeps bringing to my mind a product that I knew about when I worked for ZAC Catalogs (way back in the day). I would daresay that none of you had even heard of it (although we did pick it up as a result of Xtras carrying it, so maybe a few of you knew about it). I believe it was a called "MFC DataGrid Wizard" or something like that. Anyway what it did was build a custom DataGrid component for you based on selections in a wizard. You selected what features you needed and then it would take it’s full-featured Grid source code (which came with the component) and would dynamically generate a full blown component for you with just the features you needed.

There are two reasons this has become a topic for discussion for me. The first is that we are currently struggling with a set of third party components that a prior developer/manager pushed all over our main site. The components are ones that you have probably heard great things about them and they are pretty cool. The problem is when you shove these components everywhere! We are having ViewState issues among other things... One of the components is a full-featured Grid control (client-side) that while nice we usually only use as a glorified listbox (we use it for selecting an item). As a result I built a specialized DataGrid for our company (one that I’ll be doing a walkthrough on its codebase at the first TUX user group meeting next month)

The other reason is this post from Bertrand LeRoy where he talks about a simple grid for ASP.NET. Here’s my problem with Bertrand’s post. The grid he talks about as being simple really doesn’t sound all that simple to my ears. Let me list a couple features:

Column drag/drop
Different column types
Data Sorting/Paging
Inline editing

Now mind you these are awesome features if you need them all then you would want to use something like this, but a lot of times what we need is something simpler. You could use the aforementioned grid for this, but the grid will probably still use ViewState (because it needs it maintain state for the paging, sorting, and editing features). It might need several more scripts or <shudder /> it’s script might be 500-1000 lines longer because of the added features.

A Better Way

I have been thinking about a better way to "do" script components. We really need to have a wizard that asks us what we will be needing in the components and then the main script file can be customized (as can the server side code) to remove certain things. It could be done really easy with templates for the script. You need a template for the main file, and additional includes based on features. The server side would work pretty much the same way. I know that no company really wants to give away their source, but even if they were able to do this for script code that would make our lives a lot easier.

Tampa User eXperience (TUX) User Group is coming September 10th, 2008…

Jay Kimble — Fri, 18 Jul 2008 03:35:18 GMT

I am proud to announce that I and a couple other guys are starting User Group that revolves around User Experience (or UX) in the MS tools eco-system. The other guys are Shawn Cady, Perry Panagopoulos, and Bill Reiss (MVP) [Bill always gets his MVP props].

I could give you all their backgrounds, but I’ll make them do it at the first meeting. I’m sure Papa Fish (aka www.devfish.net) the local MS Dev Evangelist (my Blog Father) Joe Healy will be around (at least for the first meeting).

TUX' Focus
Our focus will be on the "now" of Ajax and how it integrates with ASP.NET (in all its various forms), and the "future" of Silverlight2, and anything in between (like adding Silverlight2 controls to Ajax sites, etc); we’ll not be stuck in just Web either... we’ll probably do some WPF as well. We’ll also be dealing with some of those more abstract things that you need to get better at (like how to be a better designer, creating good user experiences, etc.), and we will do our best to keep this group "devsigner-friendly" (devsigner is a developer who is also a designer).

We have a lot of really creative ideas to make this fun and useful to you today as well as with an eye for the future (but I don’t want to blow them all)... We will definitely keep this interactive and will try to help you solve your problems as well (at least we’ll be around to chat with you before and afterward).

First Talk: Intro To MS Ajax Scripting
The first person to present will be me. I will be pulling a talk out of my paid pile which means that you have probably never seen me give this talk (unless you work at one of the companies I gave it at)... this is very special and will never be repeated (well, maybe). This talk is one that I have yet to see anyone give (for free). It’s an introduction to the MS Ajax scripting framework. Oftentimes you see a demo where someone shows you how to build an Ajax Extender control where a JavaScript is thrown in, but rarely (I’ve never seen it done) does someone talk to you about building the script behavior which is used to create the Server-Side Extender (I will in fact be doing just this). You will leave this talk with the knowledge of how to do it. As is often the case when I talk about JavaScript, I’ll end with a Script# demo which will make your life a lot easier (so we’ll build the last demo in C# which will be compiled to MS Ajax-style JavaScript); this big demo is a selection grid behavior that I built for my employer to replace a commercial grid component that we were using; you’ll definitely have a use for it.

Bonus
We’ll have Pizza provided by Answers Systems, so just get there after work... you don’t need to eat first.

AND!!!! Bill Reiss (MVP) has graciously given us an MSDN Premium Subscription (used to be MSDN Universal) to give away, so don’t miss it.

Where/When will it be?
We will be holding these events at my workplace: Answers Systems in Oldsmar, FL. Better directions than this will follow in the near future (we will have a web site soon), but it’s right next to (West of) the Oldsmar Fleamarket on Tampa Rd (aka Hillsborough Ave). We plan to open the doors at 6:30pm with the activities starting at 7:00pm.

Can’t make it, but you really wanted to see my session?
<sarcasm>So you are in my fan club (Eric Wise, I know that’s you since you maintain some of my stellar code), but you live in another state (like say the cold state of Ohio... where it’s 40 degrees Fahrenheit in August) so there is no way you could see this session by me, but you really, really want to see it, but the plane ticket is so expensive.</sarcasm>

Well, we plan on videoing our sessions and making them available online (as long as the speaker is OK with it, and I am... SO this is the LAST time I’ll be able to charge for this session... unless I revamp it which I will).

Afterwards...
I’m not Joe Healy so I can’t pick up the tab, but there is a Starbucks down the street that many of my colleagues and I like to frequent (Stimulants... I need a good stimulant not a depressant... but we could be talked into depressants), so don’t be surprised if we all end up somewhere afterwards or maybe somewhere else...

RSVP
If you plan on coming please drop me a line via the contact form on this site. We need this to help us figure out how much Pizza to buy.

PS
In October (the 2nd Wednesday), Bill will be doing a Silverlight2 talk (He’s a Silverlight MVP and a soon-to-be Silverlight book author). It will be more of an intro, but he plans on really giving a nice overview from both the diesgn standpoint and the development standpoint.

And, yes, we actually have a a list of things we’re thinking about for November... nothing definitive (yet), but we plan on being way ahead of the game (as best as we can).

Types of Silverlight2 apps

Jay Kimble — Mon, 07 Jul 2008 21:03:02 GMT

I want to go on record for a prediction. I believe when the dust settles with Silverlight2 (SL2, hereafter), we will have 2 major types of apps. To me this is fairly obvious, but if all you did was look at SL2 tutorials you would get a different view altogether. You see all the tutorials that exist out there show you what I think is the preferred way: a single application that lives in the browser as a plugin.

I also see another SL2 type of app: the SL2 enhanced Ajax App. Seriously, there will be those who will use some of the fancy SL2 controls (and I’m talking about the third party ones that will be developed) to bring their Ajax apps into a new domain. So from a plumbing perspective they will stick with the familiar page model we have today. I think the draw of Ajax is strong and I would rather this not happen because it is my view that the SL2 framework is way better than classic DHTML/Ajax/Web2.0. There are those who will say, "I can’t leave the rich experience of JS on the client." (phooey... just code in DLR JScript instead if you want JavaScript).

BTW, I also see a third model. The old model built with a single Sl2 applet on each page. I think this will be a minor idea, but I see it coming.

-----------

On another note, I’ll be putting up a few SL2 posts. I have been doing a fair bit of work with it in the last month or so. It definitely involves a slightly different mentality than classic web apps.

My SL2 prototype actually uses a REST service built with MS MVC and with the MVC Contrib project’s Restful feature. I will write some on this in the not too distant future. I have really grown to like REST (and building a service the way I have is really great for quick prototyping).

I’m actually starting to chew on Databinding (and doing CRUD operations on the data), so in time I’ll be writing about some of that stuff too.

--------------

Additionally, I am also working on starting a .NET UX user group here in Tampa Bay. I’m working with a couple of the local personalities to bring together a really good group. The group would focus on MS Ajax (and other Ajax Frameworks with ASP.NET and MS MVC) and Silverlight2 based apps. I can’t wait. It’s really exciting!