One of the tools I have been using is Selenium. Selenium is a test framework for web applications. Selenium is composed of 3 different projects:

• Selenium Core: A set of cross browser javascript classes that contain the test framework.
• Selenium IDE: A FireFox plugin that allows creation, recording and editing of tests for Selenium.
• Selenium RC: A web server and a set of classes to allow integrating Selenium tests in test applications like MbUnit.

To illustrate the concepts I’m going to use a sample. I have a control called ListControlMediator, that is used to connect two DropDownList controls in order to move ListItems from a DropDownList to the other. It can be used to reorder ListItems too. The following image shows two DropDownLists with a ListControlMediator:

The identifier is shown near the controls on the page.

The ListControlMediator can work in server side mode, performing a postback each time a button is pressed. However, it also has a client side mode that uses javascript to avoid postbacks. So I want to write some tests to check that the control works properly in client and server side mode, using IE and FireFox.
 
The first thing will be to create a page to perform the tests, as the one shown above. The only functionality of the page shown above is the action to perform when the “Send” button is clicked.  When the “Send” button is clicked, the text of the items of the ListBox2 is shown in the lResult label (separated with spaces).

The second thing to do is to create a test of the web page. In this step, there are two main options:

• Create the test by hand.
• Record the test with the Selenium IDE.

I usually record the test with the Selenium IDE and then adjust it a bit. To use the Selenium IDE just open FireFox and select Tools->Selenium IDE. Use the record button to start recording actions:

For example, after some actions in the page I got the following actions recorded:

As you can see, an action can have up to 3 attributes: Command, Target and Value. If you click on an action, you can select a command from the combo box. There are a lot of commands available, but you can learn them when you need them. The reference at the bottom of the Selenium IDE shows the help for the selected command, and the arguments it takes (Target is the first argument and Value is the second argument).

A cool thing about the Selenium IDE is that it adds an option in the FireFox context menu called “Show All Available Commands”. When you right click in an element of the page, it will show a list of the most common commands that can be applied to that element. That is very helpful for newbies.

After a test has been recorded, we can save it to replay it later (using File->Save Test). As a test is not more than a list of actions, and an action can have up to 3 attributes, tests are saved as HTML pages with a table. Each row in the table is an action, and has three columns, one per attribute of the action.

Once you have some tests saved, you can use the Selenium core to test them. Several tests are grouped in a “Test Suite”. A test suite is also an HTML file with a table, where each row in the table has only one column, where a link to the test of the suite is specified.

To use the Selenium core you will have to copy the “core” directory of the selenium core distribution to the root folder of your website. In the selenium core distribution, there is also a directory called “tests” where there are a lot of tests of a test suite. Create a directory called “tests” in the root folder of your website and copy the TestSuite.html file found in the “tests” directory of the selenium core distribution. Edit the TestSuite.html file, leaving only a row in the table that points to the test saved with the Selenium IDE (copy the saved test to the “tests” directory of your website). Some tests may not work in some browsers, so you can add that information to the row. For example, if you add unless="browserVersion.isSafari" to some rows and you try to run the tests using Safari, those tests won’t be executed.

To run a test suite using the Selenium core you have to point the browser to the /core/TestRunner.html page:

And select the test suite to run on the left. After the test suite has been selected, the tests contained in the test suite are shown on the left. When you click on a test the top center part of the browser shows the actions of the selected test. In the right there are some controls to run the tests. The bottom part of the browser is where the test will be run:

The TestRunner.html page accept some parameters to select the test suite, run the test automatically, etc, but the truth is that we use Selenium RC we won’t need to mess with the TestRunner anymore.

To use Selenium RC for our web tests we don’t need to copy the core or tests from the Selenium Core distribution.

Selenium Remote Control (RC) is basically a web server and the ThoughtWorks.Selenium.Core.dll assembly.

The selenium server is used to open browser sessions and is also a proxy. When the server opens a browser session it configures the browser to use the selenium server as a proxy. The selenium server injects the test framework for the pages it uses, capturing all requests to /selenium-server/ so they return stuff from the Selenium Core, making the page under test to be able to use the Selenium Core transparently without Javascript origin policy problems.

The ThoughtWorks.Selenium.Core.dll contains types to interact with the Selenium Server, so with .NET code we can create new sessions, and perform actions with it, testing our web sites with real browsers, using our favorite testing framework (MbUnit in my case).

To start the Selenium Server you need to have JRE 1.5.0 or higher installed and type:

java.exe -jar selenium-server.jar

The server listens to port 4444 by default.

However, to automate this I have added Assembly level SetUp and TearDown methods to my web tests so the server is started before all the tests and shutdown after the tests:

From .NET you have to use the DefaultSelenium class to create a browser session. In my tests, I have a base class for web tests that has a SetUp and TearDown methods that automatically open a close a browser session:

ServerUrl, ServerPort and BaseUrl are read from the application configuration file. The Browser property is passed to the constructor of the base class for web tests.

The actual test should use perform actions in the browser session that has been opened in the SetUp method. The Selenium IDE has an option to save a test in C# format, that converts an action to a call to the browser session object, so it can be used easily from code.

Let see some code of a test (don’t try to compare it with the example of the Selenium IDE, it is different):

As you can see, it is just another way to express the actions.
 
Some thing to clarify is the CheckPageError method. Unfortunately if an ASPX page throws an exception, the assembly ThoughtWorks.Selenium.Core.dll does not throw that exception and returns OK. This is because the Selenium Server requests a page and receives a response, so it doesn’t see any problem. This is very unfortunate and I hope it will be fixed in future releases. For now what I’m doing is to check if the body of the page starts with “Server Error”. This works for me because my test website doesn’t handle custom errors and the default error handling is displayed. You may have to create your own custom CheckPageError method.

Another thing that doesn’t work as I’d expect is the Selenium.GetSelectOptions method. If the select element is empty, it returns a string array with one item that contains an empty string instead of returning an empty string array. Hopefully this will be also fixed in the future.

Note that to be able to run the tests with Selenium RC you’ll probably need to use IIS instead of the built in server of Visual Studio.

I usually test my stuff in IE and FireFox. I inherit from the class where the test methods are defined as shown here:

If you want to test with more browsers probably this will get ugly and you will have to work out a better way to run the tests without inheritance.

To test the Server Side mode in the ListControlMediator, the only required changes to the test method is to place Selenium.WaitForPageToLoad instructions after each click, so the Selenium Core waits for the postback to complete before continuing processing the test.

I hope this helps some people to enter in the world of real web tests.

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.