Tech Blog

Jay's Technical blog

C# Style Attributes in Script#/Javascript

20 December 2008
Jay Kimble

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

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

  1:// NOTE: what follows is something I could do not something that is fully working
  2:// the JS Style Attributes work and that is all
  3: 
  4: [Concern()]
  5:public myClass
  6: {
  7:public myClass()
  8:     {
  9:         Script.Literal("/*--@Concern()--*/");
 10:     }
 11: 
 12:     [Observation("When adding a person, full name should not be blank")]
 13:publicvoid When_adding_a_person_full_name_should_not_be_blank()
 14:     {
 15:         Script.Literal("/*--@Concern("When adding a person, full name should not be blank")--*/");
 16:// Test Code appears here
 17:     }
 18: }


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?

10 December 2008
Jay Kimble

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

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)
publicvoid 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

07 December 2008
Jay Kimble

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

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