Tech Blog

Jay's Technical blog

Better JavaScript class generation

24 June 2009
Jay Kimble

[WARNING! This is an archived post and as such there may be things broken/missing here.. you have been warned.]

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??

  1: compileClasses({   
  2:     testClass: {       
  3:         ctor: function() {           
  4:// this is a test       
  5:         },       
  6:private: {           
  7:             privateVar:1,           
  8:             privateMethd:function() {               
  9:// test method           
 10:             }       
 11:         },       
 12:public:{           
 13:// public stuff here           
 14:             publicVar:"2"
 15:         },       
 16:static:{           
 17://public statics           
 18:             staticVar:"test"
 19:         }   
 20:     },   
 21:     testClass2: {       
 22:         ctor: testFunc,       
 23:private: {           
 24:             privateVar2:"2"
 25:         },       
 26:public:{           
 27:             publicMethod:function() {               
 28:returntrue;           
 29:             },           
 30:             myVar:"this is a test",           
 31:             dispose:function() {           
 32:             }       
 33:         },       
 34:         implements:["Sys.IDisposable"]   
 35:     }
 36: });

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)

09 June 2009
Jay Kimble

[WARNING! This is an archived post and as such there may be things broken/missing here.. you have been warned.]

[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:

 

  1:/// <reference name="MicrosoftAjax.debug.js" />
  2:/// <reference name="MicrosoftAjaxTimer.debug.js" />
  3:/// <reference name="MicrosoftAjaxWebForms.debug.js" />
  4:/// <reference path="../ExtenderBase/BaseScripts.js" />
  5:/// <reference path="../Common/Common.js" />
  6:/// <reference path="../RoundedCorners/RoundedCornersBehavior.js" />
  7: /// <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:

  1: <script src="Scripts/MicrosoftAjax.js" type="text/javascript"></script>
  2: <script src="Scripts/jquery-1.3.2.js" type="text/javascript"></script>
  3: <script src="Scripts/JqueryPlugin/jquery.MicrosoftAjax.js" type="text/javascript"></script>
  4: 
  5: <script src="Scripts/MicrosoftAjaxTimer.js" type="text/javascript"></script>   
  6: <script src="Scripts/MicrosoftAjaxWebForms.js" type="text/javascript"></script>   
  7: <script src="Scripts/AjaxCT/AjaxControlToolkit.ExtenderBase.BaseScripts.js" type="text/javascript"></script>
  8: <script src="Scripts/AjaxCT/AjaxControlToolkit.Common.Common.js" type="text/javascript"></script>
  9: <script src="Scripts/AjaxCT/AjaxControlToolkit.RoundedCorners.RoundedCornersBehavior.js" type="text/javascript"></script>
 10: <script src="Scripts/AjaxCT/AjaxControlToolkit.Compat.Timer.Timer.js" type="text/javascript"></script>
 11: <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:

  1: $().ready(function() {
  2:     $(".box").create(AjaxControlToolkit.DropShadowBehavior,
  3:             {
  4:                 Opacity: 0.3,
  5:                 Rounded: false,
  6:                 TrackPosition: true,
  7:                 Width: 5
  8:             });
  9: });

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.


Tampa ux&hellip; Meeting tomorrow night (Wed. June 10th, 2009).. 7:30pm

09 June 2009
Jay Kimble

[WARNING! This is an archived post and as such there may be things broken/missing here.. you have been warned.]

We are meeting at Buffalo Wild Wings across the street from our normal location tomorrow night. If you have had any complaints or suggestions about how we run Tampa UX, you need to be there. It’s an important meeting. We have some ideas that we want to run by you guys and see what you guys think.. We can’t do this without you!


clientscript as the view controller

01 June 2009
Jay Kimble

[WARNING! This is an archived post and as such there may be things broken/missing here.. you have been warned.]

I’m finalizing my demos for next week’s talk at the Tampa ASP.NET MVC user group. I’m also in the midst of a deploy to our test servers of among other things a page that is an experimental architecture for me and my team. I was talking with my boss (Perry for those of you who attend Tampa UX). He had to do a little touch up on my quickly thrown together UI. He told me after playing with it that he really liked how it performs and even how it works. He thinks it’s a pretty good UX.

It’s actually very similar to DT Mini Mint (the app I’ll show at Tampa ASP.NET MVC user group next week).

The idea behind it is that the initial page is pushed out by the server and then additional data is retrieved on the fly via services (or JSON views in MVC) using JavaScript; additional functions like updates, deletes, adds, and more complex operations use the same mechanism.. so the page never refreshes once it has been rendered the first time (no, I’m not using any kind of partial view in any of my examples.. not that I couldn’t, but I don’t have that much to render in either app).

I jokingly referred to “Jay’s Dream Architecture” on Twitter, but was never really able to fully quantify what I was talking about. I likened it to MVC where the model was the service, and the controller was the JavaScript code..

After Christopher Bennage came to Tampa UX last month, we came up with a term (that I’m sure already existed): JavaScript View Controller (or JC). I loved annoying Christopher by saying I was going to attribute the MVCJC pattern to him (it seems he really loves the over use of letters in Pattern names <smile />). So remember he came up with the name for this pattern…

I’m finding more and more that I am building key pages (not all pages) that have everything they need to get started but then user interactions that would normally cause a Postback or a Ajax Postback (for an UpdatePanel), etc. I’m replacing with a client-side Ajax call to a service (for WebForms) or a client-side Ajax call to a controller action (for ASP.NET MVC). The end result is a fairly responsive UI that gives me options.

Back to my discussion with my boss today.. One of the things we realized is that side effect of this is there is an occasion where I have in memory the all the data in memory for render a client side paged grid (we’re talking at most 1000 rows of data… more like no more than 700 rows.. probably much smaller than that). We realized with this architecture and the rows in memory we could easily let the user filter the results client-side via textbox that updates the grid after filtering by the value in the test box.. without any hops back to the server)..

A similar thing for my ASP.NET MVC talk in 2 weeks is that I’m going to be replacing a standard select with an autocomplete text box that uses the original select’s options array as the source for the autocomplete suggestions text (you’ll be able to type something new and that new item will be dynamically added to the DB on save). The idea is that the client browser has pieces of data already and doesn’t need to retrieve it. There are also Jquery cache plugins that can help with this (something I won’t be showing)..

Bottom line is that the client is a for real place where we can write code and make the user’s experience better (I know I’ve not been one to totally go gaga in this arena in the past, but I’m starting to warm to it.. I think Jquery is the big reason why, too.. it’s very mature and really makes it easy to write complex interactions without writing tons of code..)