In previous posts about MS AJAX, we have been studying the new elements introduced in the web.config for a new project that uses Microsoft ASP.NET AJAX Extensions. The last thing we have to study is the ScriptModule HttpModule:

The ScriptModule is necessary to provide 3 features needed by the MS AJAX:

• To allow page redirection in a partial page update.
• To be able to call page methods instead of web service methods.
• To serve some files to the users skipping the standard authorization mechanism.

Let’s see how those features are implemented. The ScriptModule handles three HttpApplication events:

• PreSendRequestHeaders
• PostAcquireRequestState
• AuthenticateRequest

The PreSendRequestHeaders event is raised before the server sends the headers to the browser, and it is the last chance to modify them. The ScriptModule handles this event, and checks if the current response code is 302, emitted when you call to the Response.Redirect method.

As we will see when we study the UpdatePanel, it allows partial page updates, generating XMLHttp requests. A partial page update has a request header of type "X-MicrosoftAjax" with a value of “Delta=true”. However, as the response of this request is handled internally by the MS AJAX runtime instead of the browser, the redirect wasn’t working. The ScriptModule fixes this problem, because when a redirect is found for a partial page update request, it clears the response (headers and content), maintaining the cookie collection and returning a string as the content of the response. The content of the response is obtained by calling the EncodeString method of an internal class called PageRequestManager. This class plays a key role in the MS AJAX infrastructure and will be studied in detail in future posts. For now, we’re only interested in the EncodeString method, that has 3 main parameters (type, id and content) and generates a string that looks like this:

Length + ‘|’ + type + ‘|’ + id + ‘|’ + content + ‘|’

Encoding the characters “\u0000” and “\u00ff”.

In the client side, when the response has been received, the _onFormSubmitCompleted method of the PageRequestManager class checks the type of command specified, and acts accordingly.

When a redirect is found in response for a partial page update, the ScriptModule generates a string of type “pageRedirect”, where the redirect location is stored in the content. The client side handles this command as shown below:

making the redirect work as expected.

One thing to point is that the ScriptModule checks if a rest call has generated a redirect, throwing and exception in that case. This is done for security reasons.

The PostAcquireRequestState event is raised after the session data has been obtained. If the request is for a class that implements System.Web.UI.Page and it is a rest method call, the WebServiceData class (that was explained in a previous post) is used to call the requested method from the Page. After the method has been called, the CompleteRequest method is called, bypassing all pipeline events and executing the EndRequest method. This allows MS AJAX to be able to call a method on a page instead of having to create a web service to call a method.

The AuthenticateRequest event is raised after the identity of the current user has been established. The handler for this event sets the SkipAuthorization property of the HttpContext for the current request. This property is checked in the authorization module to see if it has to omit authorization checking for the requested url. Usually an HttpModule use this property to allow anonymous access to some resources (for example, the Login Page if we’re using forms authentication). In our scenario, the ScriptModule sets the SkipAuthorization to true if the requested url is scriptresource.axd or if the authorization module is enabled and the request is a rest request to the authorization web service.

As you can see, the ScriptModule isn’t terribly complicated but it is necessary to have the MS AJAX infrastructure working properly.

If we check the AJAX ASP.NET Extensions server side source code, we have now studied about a 33% of it and we haven’t done anything more than study the new infrastructure elements provided for a MS AJAX application in the web.config. The most interesting stuff is to come.

In the next posts I’ll talk about the ScriptManager control.

Where were we?

In my previous posts about MS AJAX Extensions I talked about the additions to the web.config, Serialization, proxy generation, and ScriptHandlerFactory, that is the factory that handles *.asmx requests and *_AppService.axd requests. To refresh memory, what the ScriptHandlerFactory does is to check if the request has application/json ContentType (a REST method request) or the request path ends with /js or /jsdebug (a REST client proxy request). If it is a REST method request (http://localhost/AJAXServerSide1/AjaxWebService.asmx/GetModifiedUser), it gets the web service data, calls the requested method and returns the result. If it is a REST client proxy request (http://localhost/AJAXServerSide1/AjaxWebService.asmx/js), it returns the generated client proxy. If it isn’t a REST method request or a REST client proxy request, it delegates the request to the “normal” *.asmx HttpHandler.

The  HttpHandler for *_AppService.axd exists to allow the developer to use some application services with AJAX. The only available application services available in v1.0 are Profile_JSON_AppService.axd and Authentication_JSON_AppService.axd. The profile service exposes the methods:

• GetAllPropertiesForCurrentUser
• GetPropertiesForCurrentUser
•  SetPropertiesForCurrentUser.

The authentication service exposes the following methods:

• Login
• Logout

To use the services, we have to enable them in the web.config. For the profile service, we have to set the properties that can be read and write by MS AJAX. For the authentication service we can specify if it requires SSL or not.

There is a role service that exposes the method GetRolesForUser but it isn’t enabled in the current version.
The default implementation of the services can be changed, but I won’t be touching that until we study the ScriptManager.

The last HttpHandler that MS AJAX adds to the web.config is the ScriptResourceHandler, for the path ScriptResource.axd. Lets study it in more detail…

ScriptResourceHandler in detail

The main function performed by the ScriptResourceHandler is to load scripts from resources stored in the assembly and adding localized resources to the scripts.

A request to the ScriptResource.axd must be done at the root level for the application (~/ScriptResource.axd). The request has the information needed to process it encrypted in the query string (the encryption and decryption process is done using the EncryptString and DecryptString methods of the System.Web.UI.Page class). The decrypted format for the query string is:

“d=” + 1 character that indicates additional processing + assembly name + ‘|’ + resource name + ‘|’ + cultureName.

The first character can be ‘u’, ‘U’, ‘z’ or ‘Z’. An uppercase character indicates that the feature is enabled and the lowercase character indicates that the feature is disabled. The ‘Z’ indicates that the resource has to be compressed (using GZip). The ‘U’ indicates to add some code to the end of the script, to notify the MS AJAX runtime that script has been loaded. The code that gets added to the script is:

The assembly name and the resource name must be specified. If not, an error 404 (page not found) will be returned. The culture name is used to set the CurrentThead.CurrentUICulture property. If no culture is specified, the invariant culture is used.

To expose resources stored in an assembly, the assembly level attributes ScriptResourceAttribute and WebResourceAttribute have to be used.

The ScriptResourceAttribute has 3 important properties: ScriptName, ScriptResourceName and TypeName. The ScriptName property will be compared to the requested resource name. ScriptResourceName points to a resource file that contains strings. The TypeName property specifies a script type that will be created containing the localized strings (of the CurrentUICulture, or the default ones if no CurrentUICulture specific resources exist) present in the resource specified by ScriptResourceName.

The WebResourceAttribute has 3 important properties: WebResource, ContentType and PerformSubstitution. The WebResource property will be compared to the requested resource. ContentType specifies the type of data stored in the resource and will be used to write the ContentType for the response. The PerformSubstitution property is used by the ScriptResourceHandler in order to convert expressions like:

To the URL of the resource. If WebResource is used, the generated URL will start with “WebResource.axd?d=”. For ScriptResource, the generated URL will start with “ScriptResource.axd?d=”. The substitution is performed using regular expressions.

When a resource in an assembly is requested, the assembly is inspected for the assembly level attributes ScriptResourceAttribute and WebResourceAttribute. Information about the requested resource is stored in the class ScriptResourceInfo, that has the properties of ScriptResourceAttribute and WebResourceAttribute combined. For the same resource name, we can have a ScriptResourceAttribute and a WebResourceAttribute. If only ScriptResourceAttribute is specified, the default content type is "application/x-javascript". The ScriptResourceInfo is cached using the assembly and resource name as the cache key.

When a resource that ends with .debug.js is requested, the release mode resource (resource name that ends with .js) is also requested. At least one of those resources has to exist.

If we have set the property EnableCaching for the ScriptResourceHandler in the configuration section, the response will be cached using the ASP.NET output cache by the server for a year.

The response will be generated in 3 steps:

• The requested resource will be read using the GetManifestResourceStream method from the Assembly class.  If PerformSubstitution is enabled, the substitution explained above is performed.
• If the ScriptResourceAttribute is used, a ResourceManager for the resource file with the localized resources is obtained, and some script is added to save the resources (see the code below)
• If the MS AJAX runtime has to be notified of the loading of the script, add the script line shown above.

Example

If we have the following assembly level attributes:

The file MyResources.JScript1.js is like this:

The file MyStrings.resx has the string named String1 = “This is a test”, when the resource “MyResources.JScript1.js” is requested, the response content is:

If you add another resource file to localize the resources for spanish (MyStrings.es-ES.resx) and configure the application to use the Spanish UI culture, the response for the resource “MyResources.JScript1.js” is:

That's all for now. In a next post I'll finally finish explaining all the elements present in the web.config for an asp.net ajax application.

In my last post about MS AJAX I gave a brief explanation about the web.config changes needed and explained the serialization process.

Now, I'm going to explain how a client proxy is generated. As I told in the last post, the WebServiceClientProxyGenerator.GetClientProxyScript method was were all the job was done.

There are a few classes involved in the client proxy generation:

• WebServiceTypeData, that is used to store type information about the web service to call.
• WebServiceMethodData, that is used to store information about a web service method (parameters, return type, caching, etc), and it has the functionality to invoke the method.
• WebServiceParameterData, used to store information about a parameter of a web service method.
• WebServiceData. This class uses the previous classes and has a lot of logic. Basically a WebServiceData instance is created for each web service to call (for each instance there is an associated WebServiceTypeData instance). When the web service methods are required, the EnsureMethods method uses reflection to obtain all WebMethods from the type (and its ancestors).

By default, a web service can't be called from client script. To change this, the web service needs the ScriptServiceAttribute applied to it.

To be able to call a web method from client script, the parameters and return types of the web method have to be available in client script, and the web service needs to have the WebMethodAttribute (the ScriptMethodAttribute should be used only to override the default invocation method and respone format, that is HTTP POST and JSON). If a web service method needs a parameter of a custom type, we have to use the GenerateScriptTypeAttribute attribute in the method or in the web service so MS AJAX will automatically generate a client side class for that type.

So when the methods are processed, the ClientTypes property will be filled in the ProcessClientTypes method with a list of the types that need to be available in client script.

However, the automatic type generation has some limitations, as the GenerateScriptTypeAttribute can not be applied to types implementing IEnumerable or IDictionary, interfaces, abstract classes, types without a public parameterless constructor, and generic types with more than one parameter.

The WebServiceData class also inherits from the JavaScriptTypeResolver class to provide string to type conversion (and viceversa) for the serialization/deserialization process. You may be wondering why the SimpleTypeResolver isn't used, but as the GenerateScriptTypeAttribute has a property called ScriptTypeId that modifies the __type field stored in the JSON, another type resolver was needed.

As you can see, the WebServiceData class does a lot of work, so to get WebServiceData instances the static method GetWebServiceData is used because it caches instances by URL.

If you don't want to create a new class for a few methods, you can add them to your ASPX page and call them directly. For this to work, the methods should be static and have the WebMethodAttribute attribute applied.

The ClientProxyGenerator class uses a WebServiceData instance and generates the client proxy code, although the code calls to the static method GetClientProxyScript of the WebServiceClientProxyGenerator class to get the generated client proxy code, because it performs caching based on the web service type and the modified time of the associated assembly.

For the following web service:

the User and Address classes were introduced in the previous post.

the generated proxy is:

The generated proxy class is called like the web service, and inherits from the Sys.Net.WebServiceProxy class, which has the functionality to invoke a web service. The class have some properties set in order call the specific web service that it is proxying, and the web methods exposed (GetModifiedUser in our case).

After the class to call the web service, the User and Address classes are created and registered to be used by client code (thanks to the GenerateScriptTypeAttribute). However, no property of the original classes is generated in client script. The core of this client classes is the call to the Sys.Net.WebServiceProxy._generateTypedConstructor method. This method creates a new class that accepts an object as a parameter for the constructor. The constructor of the class will iterate through the members of the object passed as the parameter and copy them to the current instance.

So you can create an instance of the Address class that has 2 fields (propertyOne and propertyTwo) like this:

and accessing to Address.firstField will return "firstValue".

So if you want to call the previous web service from client script you can do something like this:

when the User instance is created it contains no members, but you keep adding them in each assignment (this is how JavaScript works). You can even add nonexisting members like user.Foo = "This property doesn't exists in server code" and they will be ignored on the server side in the deserialization process.

When the GetModifiedUser method is called from client script, it generates an asynchronous HTTP request to the web service (http://localhost/AJAXServerSide1/AjaxWebService.asmx/GetModifiedUser in my case) with the following posted data:

that is passed to directly the User constructor in order to generate the returned value from the web service.

In my next post about MS AJAX I'll sumarize what we have learned and how it applies to the ScriptHandlerFactory, the application web services, and then continue with the next HttpHandler, the ScriptResourceHandler.

Some time ago I started bloging about the Client Side OOP Features of Atlas (now the Microsoft AJAX Library. The posts are here and here).

As I think that most ASP.NET developers will use mainly the server side AJAX extensions I'll start covering the internals of the server side additions to ASP.NET to support AJAX.

If you create a new Web Site in VS2005 using the "ASP.NET AJAX Enabled Web-Site" you'll see that the web.config file for this web has quite a few additions to the default one related to AJAX. The additions to the web.config are:

1) Added some custom sections handlers to configure the new AJAX features

2) Configured the "asp" tag prefix for controls in the AJAX implementation assembly:

3) Added the AJAX assembly reference to the compilation process:

4) Modified the HTTP Handlers:

5) Added an HTTP Module:

6) Added the configuration sections to configure ASP.NET AJAX (the section handlers were registered previously as explained in point 1).

The most important additions to the web.config to support the Microsoft ASP.NET AJAX Extensions (MS AJAX from now on) are point 4 and 5. As the ASP.NET HTTP pipeline is very configurable, those additions can have severe implications on how request are handled, so I'll start with them.

In the HTTP handlers section, the first line removes the default handling for the asmx extension, and the second one registers a new handler for the asmx extension. This simple changes makes that any call to a web service doesn't work as we are used to. The asmx requests now will go through the ScriptHandlerFactory.

Usually in the HTTP handlers session we register a class that implements the IHttpHanlder interface. The ProcessRequest method will be called to do all processing.

However, we can also register a class that implements an IHttpHandlerFactory. In this case, the method GetHandler will be called in the factory, returning an IHttpHandler that will handle the request. This is used when you want to return different IHttpHandler instances depending on some conditions of the request.

When a request that is handled by the ScriptHandlerFactory arrives, it checks if the request is a REST request (REST is a way to transmit data over HTTP without using any additional messaging layer. Consult wikipedia for more information about it). If it is a REST request, the RestHandlerFactory (a MS AJAX class) will take care of the request. If it isn't, the WebServiceHandlerFactory will take care of it. Probably the class WebServiceHandlerFactory won't say much to you, but this is the class that handles ASMX request in the ASP.NET 2.0, so when an ASMX request isn't a REST request, it is handled in the same way as we're used to. 

What is a REST request for MS AJAX? A REST request is an HTTP request that has the ContentType property set to "application/json" (this is called a REST method request) or an HTTP request whose path ends with "/js" or "/jsdebug" (this is called a REST client proxy request).

The RestHandlerFactory checks if the request is for a client proxy or for a REST method. If the request is for a client proxy, a RestClientProxyHandler is created and servers the request. The RestClientProxyHandler figures which client proxy has been requested, gets the client proxy and sends it. All the hard work is done by the WebServiceClientProxyGenerator.GetClientProxyScript method. Before entering in detail how the client script proxy is generated, lets see how MS AJAX handles serialization.

Data types are exchanged between client side and server side using JSON (JavaScript Object Notation). To send data to the client side from the server, the data is serialized, and to receive it from the client, the data is deserialized in the server.

The main class responsible for this serialization/deserialization process is JavaScriptSerializer. The public member for the class are:

The serialization fails if there are more nested objects than RecursionLimit or if the length of the serialized object is MaxJsonLength.

A serialized object can optionally include type information. The type information is provided by a class that inherits from JavaScriptTypeResolver, that has the following methods to get a type from a string and viceversa:

The serializer will add the type information in a field called __type if it has an associated JavaScriptTypeResolver.

As the JavaScriptSerializer can not serialize/deserialize all types, you can supply a custom class to support types not directly supported by the JavaScriptSerializer using the RegisterConverters method. A converter has to inherit from:

and it has to implement the Serialize and Deserialize methods, as well as providing the list of supported types.

The standard MS AJAX distribution doesn't have any converter, but you can find a DataSet, DataTable and DataRow converter in the ASP.NET AJAX Futures release.

The other methods of the JavaScriptSerializer class are just serialize/deserialize variants, and the ConvertToType method that will be explained later.

The serialization of the basic types is as follows:

null or DBNull.Value -> "null"
bool -> "true" or "false"
char -> if it is '\0', "null", like a string if not
float, double -> ToString("r", CultureInfo.InvariantCulture)
DateTime -> "\/Date(number of milliseconds elapsed since midnight 1970/01/01 UTC)\/"
string -> quoted string
Guid -> "\" + ToString() + "\"
Uri -> "\" + Uri.GetComponents(UriComponents.SerializationInfoString, UriFormat.UriEscaped) + "\"
other primitive types and Decimal -> IConvertible.ToString(CultureInfo.InvariantCulture)
Enum -> serialize the integer value of the enum
IDictionary -> JSON object
IEnumerable -> JSON array

A custom object is serialized as a JSON object with the optional member "__type" : typeName obtained using the JavaScriptResolver, where the other members are obtained from the public instance fields and public instance properties without the ScriptIgnore attribute applied.

for more information about JSON take a look here.

A Hashtable that compare references is used to throw an error if there is any circular reference.

Lets show an example of the serialization process. I'm going to use this User and Address class:

With the following code:

The SimpleTypeResolver inherits from the JavaScriptTypeResolver class explained before, converting a Type a string using the AssemblyQualifiedName and viceversa.

Is serialized as:

Note that the FullName property of the User is not serialized because the ScriptIgnore attribute.

The deserialization process is delegated to the JavaScriptObjectDeserializer class. This class uses the JavaScriptString and the ObjectConverter class. The JavaScriptString class is a helper class used to tokenize the JSON data. As when the data is serialized all types are converted to JSON types (strings, numbers, JSON objects and JSON arrays) some kind of conversion back to the original type must take place. The JavaScriptObjectDeserializer does some simple conversions like checking if a string is a character, a boolean, a date or a null value, most significant conversions are handled by the ConvertObjectToTypeInternal method of the ObjectConverter class.

The ConvertObjectToTypeInternal uses the __type field, source object type and destination type to perform the convertion. If the source data is of type IDictionary it tries to create an object of the destination type and sets its fields and properties with the values stored in the dictionary. If the source data is of type IList, it tries to create a collection of the destination type and adds each of the items of the list to the collection. If the collection is a generic collection, it extract the item type of the collection and tries to convert the items as they're added to the collection.

If the source type isn't neither an IDictionary nor an IList, it gets the TypeConverter for the destination type and check if the source data can be converted to that type. If the source type doesn't have a conversion to the destination type, it converts the source type to a string and then tries to convert that string to the destination type (all of the conversion that involve the TypeConverter use the InvariantCulture).

If everything fails, a conversion exception is thrown.

To continue the previous example, this converts the string obtained from the Serialize method back to an User instance:

When comparing the initial User instance with the deserialized one, the CreationDate is different by one hour (at least in my machine), so there is a bug in the MS AJAX code that handles DateTimes :-(

One curious thing about serialization is that the property names are case insensitive when deserializing an object, as the AssignToPropertyOrField method uses the BindingFlags.IgnoreCase to retrieve properties and fields. However, when an object is serialized, the properties for the client code are case sensitive.

I have run out of time for this week but soon I'll continue with the internals of the additions of MS AJAX to the web.config.

Another year ends and a new one comes. Life goes as fast as usual and we’re keep on our way. It’s time to think about it… our actions, hopes, wishes, mistakes, etc.

I usually listen to a special song a few minutes after the start of the year. In the last few years I have been choosing "Aerosmith – Full Circle" because it has special connotations for me.

I wish you the best in the coming year.

I have spent most of the last weeks changing some designs to use pure CSS layouts instead of table based designs and having to support IE 5.0+.  So you can imagine my frustation level. It’s really sad to see the required work to make a complex design work in IE 5.0, IE 5.5 MAC IE 5, IE 6, IE 7, Firefox, Safari and Opera. IE versions prior to IE 6 are really terrible in CSS compliance and you need to have solid IE bug theory to fix those limitations.

It is really sad that here (in Spain) and maybe in other countries too, there are still a significative percentage of users using IE 5.0 and IE 5.5. IMO there should be some kind of movement to delete old browsers from the earth. For example, in Europe there will be an analogic TV shutdown before 2012. There should be something similar periodically for old browsers. For example every year most of the webpages should use an updated script to completely fail in browsers older than 2 or 3 years, forcing the people to upgrade because most of the webpages they visit will not work for them (as some people will only upgrade for that reason).

Talking about browsers, it is sad to see that IE 7 does not pass the ACID2 tests. Also Firefox, the browser that claimed to be more standard compliant than IE and that will save our souls, doesn’t pass the ACID2 tests either (in the 2.0 release). The first version of Firefox was very good compared to the browsers out there but now they haven’t improved it very much lately. Anyway, the developer extensions for firefox are so good that it is a must have. I was very surprised with Opera 9 because it passed ACID2 tests, has finally added support for rich text editing so things like R.A.D. editor (www.telerik.com) finally works and it has an excellent zoom tool, not like the Firefox one that the only thing that does is to break all pages when you zoom a bit.

But to be fair, a big part of the problems are because of the lack of a reference implementation by the W3C. CSS will be better designed and more trouble free with a reference implementation so the people defining and implementing the standard can play with. It won’t be too difficult to produce automated tests to compare rendered web pages with different implementations of the standard using a common set of stylesheets and fonts, so a pixel perfect comparision will be possible if the rendering engines do not employ any dithering. Having a reference implementation to play with will also help in making a more robust and useful specification (why is so complex to align something vertically in CSS when aligning it horizontally is trivial?).

Will this situation change some day? It is changing slowly but with some help it will be able to change faster and let us focus in real problems and not in stupid incompatibility problems that only causes us headaches and slow down web evolution.

Note: Bertrand Le Roy has confirmed that the next Microsoft AJAX Library release will use the prototype based approach instead of the closure approach (really great news!), and clearly explains the differences:

http://weblogs.asp.net/bleroy/archive/2006/10/11/From-closures-to-prototypes_2C00_-part-1.aspx

In part 1 we saw how the inheritance infrastructure worked, how to create namespaces, and how to create classes. Now it is time to continue with the other stuff.

Interfaces

To create an interface is similar to create a class, but we use the registerInterface method instead and we define the methods to be abstract. For example:

We can define the interface using the prototype method instead of the closure method:

The registerInterface method (defined in the Function type) just set the _typeName of the type where the method is invoked, and sets the boolean properties _interface, _abstract and _sealed to true.

Enumerations

There are two kinds of enumerations that we can create. One where the enumeration items act as flags so we may want to combine them and the other type is where we can’t combine the enumeration items.

The first type is created using the createFlags method and the second one is created using the createEnum method (of the Type class). The parameters for those methods are:

Type.createFlags(enumerationName, enumerationItems)
Type.createEnum(enumerationName, enumerationItems)

Where enumerationName is the name of the enumeration, and enumerationItems are a variable number of parameters that specify the different enumeration items. Each item in the enumeration is specified as two parameters, the first is the string with the item name, and the second the associated value.

The common methods are:
• toString: converts the value passed to the method to a string.
• parse: converts the string passed to a value.
• getName: returns the name of the enumeration

The enumeration where you can use the items as flags has a method called isFlags that return true. The other enumeration type has a method called isEnum that returns true, and a method called getValues that returns a hashtable with the items of the enumeration.

An example follows:

The values of the variables after execution are:

val = 1
str = “enum_item1”
valaux = 2
val2 = 5
str2 = “enum_item1 | enum_item3”
val2aux = 6

Both kinds of enumerations are implemented the same way. A hashtable with the same name as the enumeration is created, and each enumeration item name is stored as a key of the hashtable and the enumeration item value is stored as the associated value for the key.

From now on, when showing a class or an interface, I’ll be using C# syntax to show it instead of the JavaScript version of the class for clarity. The naming convention for the JavaScript classes is distinct from the C# naming convention so if a property is called Text in C#, the equivalent getter and setter will be get_text and set_text instead of get_Text and set_Text, so don’t get confused.

Attributes

In .NET is very common to decorate classes, properties and methods with attributes that provide useful information about them. The Microsoft AJAX library adds this extension to JavaScript.

The attributes are very important to generate reusable code. The xml-script parsing process and the validation controls use it.

An attribute is a static property of the class Sys.Attributes. The class has a method called defineAttribute that creates a new attribute:

After having created the attribute we can reference it using Sys.Attributes. 'MyCustomAttribute. The attributes can be associated to a class or to a property as we will see in the next section.

Reflection

Even if JavaScript has some flexibility that can be used to perform some tasks similar to what reflection does (retrieve all fields from an object, retrieve a field from an instance using a string with the property name, invoke a method from an object based on the method name, etc), as the Microsoft AJAX library added OO features to it, it has to provide a way to interact with all the new OO infrastructure generically and more .NET friendly.

These features are provided by the Sys.TypeDescriptor class. Most of the classes in the library implement the interface ITypeDescriptorProvider:

The only method present in the interface returns the TypeDescriptor for the class implementing the interface.

The TypeDescriptor class is like this:

A class implementing ITypeDescriptorProvider returns a new instance of the TypeDescriptor class where all the attributes, properties, methods are events supported by the class have been added using the AddXXX instance methods. The CreateParameter method is used with the AddMethod method to specify the parameters for the method.

The information about a particular instance is stored in four dictionaries (_attributes, _events, _methods and _properties). The static methods AddType and GetType are used to register types and to get information about the registered types in the system. The TypeDescriptor class has a static field called _registeredTags (of type hashtable), where it stores a hashtable of typeNames and its associated type, using the tagPrefix as key. This is mainly used by the xml-script infrastructure as we’ll see in a future post. The Unload method erases the information stored in the _registeredTags hashtable.

The other methods are self explanatory.

Events

The event mechanism implemented by the library is very reminiscent of the .NET one, although it has some differences.

An event is an instance of the Type.Event class:

An event is declared like this:

And to subscribe to the event we have to write the following code:

the onPropertyChange method will be called when the event is fired. The method should have a signature like this:

And the first parameter will be the object that fired the event, and the second parameter will be the arguments specific for the event.

The arguments are an instance of the class EventArgs or any of its subclasses:

Note that the EventArgs class implements the ITypeDescriptorProvider interface explained before.

The Event class implements the IDisposable interface that is like this:

yes, the same as .NET.

The Event class has methods to add and remove event handlers and also to add and remove actions. What is an action? Actions will be covered in more detail in a future post but for now think of them as tasks that can be executed before the event handler is called or after the event handler is called.

The Event constructor takes a Component as the first parameter, because actions operate on components. The autoInvoke parameter is used to call to a handler when adding it to the event if the event has already been fired. This is useful because some critical methods should be called in response to events that may happen before the full Microsoft AJAX Library has been initialized.

Additions to the default JavaScript objects

The library adds some methods to the default JavaScript objects to make them more .NET alike:

Boolean -> parse
Number -> parse
String -> startsWith, endsWith, lTrim, rTrim, format, localeFormat
Array -> add, addRange, cloar, clone, contains, dequeue, indexOf, foreach, insert, remove, removeAt, parse, get_length, get_Item. Also, Array implements the IArray interface (get_length, get_Item).

RegExp -> parse

Error -> createError (that is the replacement for: throw new Exception(…) in the .net framework.

Date -> toFormattedString, serialize

In the next post I’ll talk about the Component class and related classes. There is a lot of theory behind it to fully understand all the details involved…

I have started to look at Atlas. The first thing I have played with is the layer to provide better OOP features for Javascript.

Note: this is based on an early version of the product (July CTP), so this information can change for the final release.

Javascript OOP features

Javascript is a prototype-based object oriented language. This means that every object has a prototype, an object from which it inherits properties and methods. The prototype is a shared property of the class that can be accessed like this:

myClass.prototype

As Javascript is an interpreted language, when the interpreter founds an expression like:

myObject.myProperty

first it checks if the object instance “myObject” has a property called “myProperty”. If not, then it tries to find that property in the prototype object of that class (myClass.prototype.myProperty). This prototype relationship is recursive, because the prototype is an object that can have a prototype, so this recursion ends only when Object is reached, the superclass of all objects.

In Javascript, a class is defined by a function (the constructor) and its prototype (that defines the properties and methods that each object instance has by default, because of how the interpreter evaluates the expressions).

So, to define a class in Javascript we have to do this:

If we want to add a method to the class we can do it like this:

Or like this:

What's the difference? Consider the following class:

If we instantiate two objects of the class TestClass, we can see the difference:

This diagram shows the internal representation of the object:

As you can see, the method declared using the prototype is shared between instances of the class. However, the method added in the constructor is created for each instance. So:

objTestClass1.method1 != objTestClass2.method1
and
objTestClass1.method2 == objTestClass2.method2

Basically, the prototype is the only “object oriented mechanism” present in Javascript. As you can see it is not an usual object oriented language. Using the prototype you can come up with your own solution to simulate a more complete object oriented language (inheritance, virtual methods, calling the base method, etc).

Atlas OOP features

Atlas adds some valuable features to provide a more natural object oriented programming models. What Atlas offers is:
• namespaces
• inheritance
• properties
• defining virtual methods
• calling base methods
• interfaces
• enumerations
• attributes
• reflection

Namespaces

To create a namespace in Atlas you have to write something like:

Internally Atlas adds a Type property to the window object (the default Javascript context), and assigns it the Function built-in type. Atlas adds a lot of methods and properties to Function, as we’ll see later.

The registerNamespace function splits the namespace by the dots and creates a hierarchy of objects in the window object that resemble the namespace. For example, for the namespace Manu.Atlas.Tests the following properties are created:

Inheritance

Atlas theorically supports multiple inheritance, but in the July release it isn’t working properly. Anyway, multiple inheritance support will be removed before the final version, so don't count on it.

A class in Atlas has to be registered to work properly. The syntax to register a class is:

FullClassName.registerClass(typeName, baseTypes, interfaces)

Only the first parameter is mandatory. The second parameter specifies the base class or base classes if multiple inheritance is used. The second parameter could be a reference to the base class or an array of type names for the base class (or classes). The third parameter is the interface implemented by the class (if any). A class can implement multiple interfaces so you can call registerClass with more than 3 parameters. Any extra parameter should be an interface that is being implemented by the class.

Atlas adds some information to each class type it creates to provide the necessary machinery for the object oriented features:

• _typeName field: with the name of the type (the function getTypeName returns it).
• _baseType field: a reference to the parent type (the function getBaseType returns.
• _basePrototypePending property: a boolean that is used to know if the class has been initialized (more on this later).
• _interfaces: an array with references to the interfaces implemented by the class.
• bases: an array with references to the parent classes.
• _interface, _sealed and _abstract boolean properties to give information about the type.
• _baseMethods: a hash table where methods that can be called by child classes are stored.

The core of the inheritance mechanism is handled by the initializeBase function that has to be called in the constructor of a derived class. The syntax is:

FullClassName.initializeBase(instance, baseArguments)

Where the first parameter is the instance to be initialized and the second parameter is an array of arguments to pass to the base constructor.

The initializeBase method starts calling the constructor for each interface in the class (stored in the _interfaces collection). Then calls the _setBases method and finally calls the _callBaseConstructors method.

The _setBases method does an important job. If the class inherits from another class, the method iterates through all the base classes, filling the bases collection, and recursively calling the _setBases method on the base classes. After the _setBases method has been called for a base class, the _copyProps method is called. The _copyProps method iterates through all properties and methods stored in the prototype of the base class and stores them in them in the prototype of the subclass. So, after the call to _copyProps, the subclass also has the properties and methods specified in the prototype of the base class.

The _callBaseConstructors method iterates through the bases array, calling the base constructor with the current object instance.

So, after calling the initializeBase method, the object has all the properties and methods of the base classes, giving the illusion of inheritance.

If we declare the methods and properties in the prototype, they will be created in the child classes in the _copyProps method. If we create the properties and methods in the constructor, they will be created in the child classes in the _callBaseConstructors method.

An example of a class B that inherits from A is:

Note that we have created the properties and methods using the prototype in order to save memory. We can declare the A class like this:

And it will be functionally equivalent although it will be more expensive in memory terms as each object instance will have 4 methods instead of sharing them (as explained before). This mode of creating a class is called the closure model. The previous one is called the prototype mode.

If we create an object of type B, we can call the base properties. In the following sample, the last line evaluates to 3:

There are more functions to register a class, depending on the behaviour of the class:
registerSealedClass and registerAbstractClass. The name clearly shows when to use them although they just set a property and call to the registerClass method. If a class is registered using registerSealedClass any class inheriting from it will not have its members copied because the _setBases method will not be called although no error will appear.

The Function built in type is also extended with some methods to check interface implementation, inheritance and type:
• implementsInterface
• isImplementedBy
• inheritsFrom
• isInstanceOfType

Properties

As javascript doesn't have properties like C#, the recommended approach (and what is used in the atlas library) is to provide a getter and a setter method for properties with the signature get_propertyName set_propertyName as we did earlier for the Manu.Atlas.Tests.A class. It is really important that the getter starts with "get_" and the setter with "set_" as this is mandatory for integrating our custom components into the Atlas framework as we will see in a future.

Methods

The initializeBase method provided most of the machinery for the OOP with Atlas, but there is something missing: how to call a base method from an overridden method.

Atlas provides 3 methods related to this problem:
• registerBaseMethod
• callBaseMethod
• getBaseMethod

The first one is saves a method in the _baseMethods hash table, in order for a child class to call to the base class implementation. The child class has to call to the callBaseMethod for this, and the implementation of callBaseMethod uses the getBaseMethod method in order to obtain a reference to the base method.

There is no need to call to the registerBaseMethod if we define our methods using the prototype because the getBaseMethod searchs the method in the prototype if it isn’t found in the _baseMethods hash table.

An example of a class with a method that calls the base method follows:

The Function built in type is extended with two static functions to help when creating a class or an interface:
• abstractMethod: method that throws an exception if called.
• emptyFunction: the name says it all.

I’m running out of time now so in another post I’ll finish talking about the OO features of Atlas.