December 2011

A C#/Java Developer's Rundown on JavaScript Part 1

Saturday 31 December 2011 James G


There are many developers out there who have used JQuery extensively but have not invested the time and resources in learning JavaScript as a language.

I used to be like that.

I never learnt JavaScript as a language. I just started slinging code in it and picked up a lot of bad habits.  I used it primarily to write some client side scripts to give my web applications some client side functionality. (when AJAX used to be a cool)

JavaScript is not every developer’s cup of tea especially if you are used to the static/strongly-typed languages like C# and Java.

JavaScript is a simple language with too many quirks. Mastering JavaScript is essentially understanding the quirks in the language and how to deal with them.

My next series of posts will be to give C# and Java developers a quick rundown of core JavaScript so they do not have to go through the pain that I have.

The JavaScript Type System

The JavaScript type system is very simple. It is the simplest I have seen in any language.

The JavaScript type system is divided into two categories.



These are primitive types and object types. (Just like in .NET we have the Common Type System and loosely speaking in Java we have Primitive types and Reference Types in Java.)

The Primitive types in JavaScript are numbers, strings, boolean values, null and undefined.  These are immutable.

All other JavaScript values are objects. Objects in JavaScript are simply a collection of key/ value pairs where each value points to another primitive type or an object.

And that is basically it.

Now let us take a closer look at the object type which is a collection of key/value pairs. Recall if you have studied data structures that collections can be ordered or unordered. Normal objects in JavaScript are unordered collections. For ordered collections, JavaScript provides a special type of object called hang on... an array. Really simple stuff.

JavaScript has another kind of object called a function which is essentially an object that points to some piece of executable code.  (A bit like delegates in c#).

Variable Declaration and Scoping

JavaScript variables are declared with the var keyword and are untyped. This means you can do (cringe) stuff like this
1:  (function(){  
2:    var age = 10; // age is a number  
3:    console.log(age); //10  
4:    age = age + 1;  
5:    console.log(age); // 11  
6:    age = 'eleven'; // age is now a string  
7:    console.log(age); // eleven  
8:  }());  

Basically assign and re-assign values of different types to a variable.

Just as you can use classes and methods to manage scope in C#, Java, JavaScript uses functions to achieve the same thing. Any variable declared in a function is local to that function.  If however, it is declared outside of a function, then it is a global variable.

Here is quirk that will get you thinking what the heck...

If a variable is used without being declared in a function, it is an implied global variable. 

(Yeah there is some creepy stuff in JavaScript).

Consider the code below:
1:  function calculateArea(length, breadth) {  
2:       area = length * breadth;  
3:       return area;  
4:  }  

the undeclared variable 'area' is now a global variable.

Here is another quirk.

If you declare multiple var statements in any part of a function, they act as if they were declared at the top of the function. 

This behaviour is known as hoisting.

Feast your eyes on this splendid code block below:
1:  age = 10;  
2:  function splendidCode() {  
3:    console.log(age); //undefined  
4:    var age = 20;  
5:    console.log(age); // 20  
6:  }  
7:  splendidCode();  
1:  age = 10;  
2:  function splendidCode() {  
3:    var age;  
4:    console.log(age); //undefined  
5:    age = 20;  
6:    console.log(age); // 20  
7:  }  
8:  splendidCode();  

Both chunks of code are equivalent because of  variable declarations being hoisted to the top.

One way to remedy this is to have a single var statement at the top of your function. This forces you to declare local variables and also prevent some of the quirks shown above. Used in this way, your function will look like this:
1:  function playNice() {  
2:    var age = 10,  
3:      name = '',  
4:      address={};  
5:    //sling some code here  
6:  }  
7:  playNice();  

That is all for today folks.

I wish you all a Happy New Year.

James

0

Migrating Prism based Application to Silverlight 5

Friday 30 December 2011 James G ,


I recently had to migrate a PRISM based Silverlight 4 out of browser app to Silverlight 5. (Yes we know the end is nigh but what the heck...).

The only external dependencies the application had where on
  •  Prism 4
  • Silverlight 4 toolkit

And because I was using Model View View-Model,
  •  System.Windows.Interaction.dll from the expression blend SDK.

So after all how difficult could that be?
At the time of writing this, there is no prism version specifically for Silverlight 5.


Silverlight 5 installation

First I updated my rig to Silverlight 5 by installing the Silverlight 5 Tools for Visual Studio 2010 SP1 
Then I installed the Silverlight Toolkit.

No issues so far.

I then loaded up the solution in Visual Studio and tried to compile it. WCF RIA Services then started to grumble about some “CreateRIAClientFilesTask” task failing unexpectedly.



Ok my bad. 

I had not set the target Silverlight version. I set this to 5 for every Silverlight client project in the solution.


At this point, the solution compiled successfully.  
However, when I tried to run the application another error popped up. 

The actual error message was ReflectionTypeLoadException was unhandled by user code.



At this point, I gave up and started crying like a baby.

Yeah right. I needed to show PRISM some love.

First I need to compile a version of PRISM for Silverlight 5. So I downloaded the source code for prism and rebuild it for Silverlight 5 and then replaced the PRISM references with the new Silverlight 5 ones. Then I tried again. Not working.

Dummy, I had forgotten about the Silverlight Toolkit. I replaced the Silverlight Toolkit 4 references with the Silverlight Toolkit 5 ones and tried again. Still not working.

Ahhh, System.Windows.Interaction needs to be updated as well.  Ok so I installed Expression Blend 5 beta and got a copy of this DLL and replaced it.

After that I started the app and presto it worked.

Now after some fist pumping, I have noticed a child window not correctly centred after a resize? Worked perfectly in version 4. Ok will have to fix that. Not a perfect world.

Final advice, wait for a Silverlight 5 version of PRISM if you can but then again we are in this profession because we crave the complexity...

James

2

Next posts »

Followers

Powered by Blogger.
Powered by Blogger. Designed by elogi. Converted by Smashing Blogger for LiteThemes.com. Proudly powered by Blogger.