Using Script# to build ASP.NET AJAX Enabled Controls
Recently I’ve finished reading the marvelous book ASP.NET
AJAX IN ACTION. After that I thought to start build some simple ASP.NET
and I consider most of the scripts I wrote a simple bad coding practice
scripts. So ASP.NET AJAX Scripting framework would enhance my Scripting style!
that would let me go ahead and would give a crash start. And I’ve tried a tool
made by Nikhil Kothari named Script#. A tool that lets me
I’m used to develop with.
Script# in few words is C# compiler that converts C# code to
So I started to use Script# and I was amazed
by how fast I can accomplish developing my simple controls using this tool. In
this post I’m going to show my experience with this tool and focus on things I
wished to have in it but so far it doesn’t support.
Simply when I started with Script#; I wanted to build a
simple styled TextBox control that have style when hover over it or receive a
focus or even when the TextBox is in read-only state. Very simple control isn’t
Well, Script# provides you with base classes to inherit from
if you wish to build AJAX Enabled Controls. These classes are Sys.UI.Control and Sys.UI.Behavior.
As you might notice, these classes are mapping to the Client Classes with the
with your client classes you defined in the C#. Of course your client class
generates will inherit from the client class you defined in your C# code. It is
important to note that we are talking here about client classes not the ASP.NET
Server Control classes.
The code for my classes is attached to the post, all you
need is to download the Script#, install it and compile the Projects attached.
“YourProjectName.debug.js”. The first one is the release version which is compressed
and hard to read. The other one is the debug version, not compressed and has
all your debug details on it. That means inside your C# code you may call Debug.Trace() method, this method class will not be
available in the release version of the script but of course it will be
generated in the debug version.
At the time I’m writing this post I was using Script#
v0.4.2.0. So far my comments about this wonderful tool are only 2:
fully qualified client method “Sys.UI.DomEvent.addHandlers” although there is a
simple shortcut for it which is $addHanlders. Same thing for DomEvent.AddHandler
method which has equivalent shortcut $addHandler.
Second comment is that I
face the need to use readOnly property of TextBox. TextBox will render even an input
element with type=”text” or textarea element. Both have readOnly
property that can be accessed through client code. Script# provides nearly full
as output. So in Script# input element with type = “text” and textarea
are represented as System.DHTML.TextElement
and System.DHTML.TextAreaElement respectively. The issue
here is both classes do not expose ReadOnly property!!
This issue made me access readOnly property through this code DOMAttribute att = this.Element.GetAttributeNode("readOnly");. Again facing
another issue which is browser compatibility. IE returns readOnly
property as Boolean true/false. FireFox and Opera return readOnly
property as string; empty or null if the element is not read-only and
“readonly” value if the element is read-only. A funny note, Opera returns “readOnly”
with capital O if the element is read-only.
There are some other comments, but not sure how far Script#
can reach to enable such facilities. For example, as mentioned above I had to
access readOnly property using a long line of code. This code is generated like
att = this.get_element().getAttributeNode('readOnly'); a long line comparing
to this code this.get_element().readOnly; especially if you can
save few extra lines by accessing the property directly.
Finally, Script# is
to have C# programming skills and a good vision of DOM so you can gain maximum
benefits of the Script#.