So you have been asked to create some sort of callback history, or maybe trace how you have got to a certain point and be able to “roll back” previous states of your application. I have recently discovered a very interesting use for closure callbacks that enables just the thing. Most people would freak out, but really this is just a design pattern based on linked objects in traditional languages (only more easy!).

So lets get on with the example.

var PresidentTracer = new (function(){
var presidenttracer = this;
var presidentCurrent;
var presidentCallback;
var presidentCallforward;
presidenttracer.addPresident = function(presidentName){
var current = presidentCurrent;
var callback = presidentCallback;
presidentCurrent = presidentName;

//callback history
presidentCallback = function(){
presidentCurrent = current;
presidentCallback = callback;
};
};
presidenttracer.nextPresident = function(){
var current = presidentCurrent;
var callback = presidentCallback;
var callforward = presidentCallforward;
if(presidentCallforward!=null){
presidentCallforward();
presidentCallback = function(){
presidentCurrent = current;
presidentCallback = callback;
presidentCallforward = callforward;
}
}
};
presidenttracer.previousPresident = function(){
var current = presidentCurrent;
var callback = presidentCallback;
var callforward = presidentCallforward;
if(presidentCallback!=null){
presidentCallback();
presidentCallforward = function(){
presidentCurrent = current;
presidentCallback = callback;
presidentCallforward = callforward;
}
}
};
presidenttracer.currentPresident = function(){
return presidentCurrent;
};
})();

This is basically linked lists through closures… It can get even more interesting then this though, we could if we wanted to pass in a closure to get executed on each president switch as follows.

var PresidentTracer = new (function(){
var presidenttracer = this;
var presidentCurrent;
var presidentCallback;
var presidentCallforward;
var switchCall;
presidenttracer.addPresident = function(presidentName, callOnSwitch){
var current = presidentCurrent;
var callback = presidentCallback;
var switcher = switchCall;
presidentCurrent = presidentName;
switchCall = callOnSwitch;
callOnSwitch();
//callback history
presidentCallback = function(){
switchCall = switcher;
presidentCurrent = current;
presidentCallback = callback;
};
};
presidenttracer.nextPresident = function(){
var current = presidentCurrent;
var callback = presidentCallback;
var callforward = presidentCallforward;
var switcher = switchCall;
if(presidentCallforward!=null){
presidentCallforward();
switchCall();
presidentCallback = function(){
presidentCurrent = current;
presidentCallback = callback;
presidentCallforward = callforward;
switchCall = switcher;
};
}
};
presidenttracer.previousPresident = function(){
var current = presidentCurrent;
var callback = presidentCallback;
var callforward = presidentCallforward;
var switcher = switchCall;
if(presidentCallback!=null){
presidentCallback();
switchCall();
presidentCallforward = function(){
presidentCurrent = current;
presidentCallback = callback;
presidentCallforward = callforward;
switchCall = switcher;
};
}
};
presidenttracer.currentPresident = function(){
return presidentCurrent;
};
})();

so lets test it out!!!

Over the past few years I have worked on several javascript projects, many of which use and require a class paradigm of some sort (Open API’s). So to say the least, this is an experience which is irritating for new people and is still irritating for experienced programmers. The complexity of the problem is due mostly to the fact that there are 3-4 ways to do some things in the language (this is one of them), and none of the ways to do it really is right in any traditional sense of the word.

So for the JOY of throwing another wrench in the basket, I bring you yet ANOTHER way of doing namespaces in javascript programming, but don’t worry this should be a very pleasant experience.

First let me start off with how the problem began,

• One day matt was asked to program yet another open API, and on this day matt was sad.

• The reason was because on a previous project matt had tried an object literal style of programming (the x = {}; style), of which he found private fields were not to be found, and the requirements of an object literal (for class programming) to be very limiting  with no constructor of any sort.
• He also remembered the wonders of an even earlier project, which used traditional javascript OOP programming (new operator). This style offered solutions to many of problems related to defining classes using object literals, but yet had its own set of problems. One of particular irritation was a property of javascript which makes it very difficult to build namespaced objects (which is why I think we do namespaces in JSON objects these days).
• Read about the two methods here: http://www.javascriptkit.com/javatutors/oopjs.shtml

Now being a programmer who is mandated to use jquery, he was a fish out of water. Since jquery is not a library that lends its self well to a multi-level namespace matt was forced to come up with a new method for programming namespaced API’s, regardless.. Should matt really have to rely on a library to define a namespace in javascript?? NO.

Thus I introduce to you, classical javascript OOP with namespaces. Which I would affectionately like to call “Javascript with Classes”.

Properties of javascript class programming.

• All namespace objects are anonymous instantiated singletons. Thus carry all the properties of a typical object. This levels the playing field, there are no “special” object literals.
• I have been using it for several months, it works on all browsers.
• Since everything is instantiated first, objects in the namespace may easily share references, via this.
• Namespace objects may not be instantiated, objects within the namespace may be instantiated, this method unifies classical javascript OOP and namespaces. You are able to control what objects may be instantiated with this method.
• Namespace objects have all the standard things any other function has, including privates, this, prototype, etc.

Finally, this method of javascript programming isn’t really all that special. To be honest it was looking me right in the face for the longest time, but it wasn’t until now that I get why it is important. I would say that probably the nicest thing about this method is that it unifies namespaces and classical javascript OOP, I can throw out structuring classes in object literals all together, there are also several other advantages including much cleaner code.

So enough talk, lets cut to the chase:

(The red highlighted code is the winner, when looking at simplicity)

• Lets create a namespace object called HelloWorld

Object Literal Way:
HelloWorld = {};

Classes Way:
HelloWorld = new (function(){
})();

Classical Way:
function HelloWorld(){
}

• Simple enough, lets now add another level to our namespace, say some animals.

Object Literal Way:
Notice: Whoa, where did function come from? Melding of 2 different concepts here. No concept of closures, you will see later how this can get extremely complicated, and even unsafe.

HelloWorld = {
“Animals”:{
“Bunnie”:function(){},
“Fish”:function(){},
“Bear”:function(){}
}
}

Javascript Class Way:
Notice: things stay consistent. The anonymous singletons are the namespaces, functions are the objects. Think about how closures come into play with this method.

HelloWorld = new (function(){
var hw = this;
hw.Animals = new (function(){
var animal = this;
animal.Bunnie = function(){};
animal.Fish = function(){};
animal.Bear = function(){};
})();
})();

Classical Way:
Notice:You can see where classical starts to break down with namespaces, you need to declare every level of the object. Highly irritating, if you have several levels. Everything is declared out of scope, so you will see later how closures factor into things. Also, unless you want your user to be able to instantiate HelloWorld on the fly, this is not a standard namespace. This is not really even correct in many ways..

HelloWorld = function(){}
HelloWorld.Animals = function(){};
HelloWorld.Animals.Bunnie = function(){};
HelloWorld.Animals.Fish = function(){};
HelloWorld.Animals.Bear = function(){};

• Excellent, now lets say that we wanted one function in the object domain to access another.

Object Literal Way:
Notice: Humm, notice how we had to type in the full object path here, this is one of the downfalls of object literals, in the fact that scope is not retained in the literal. This becomes highly irritating if  you at all try to create any sort of complexed javascript object model.

HelloWorld = {
Animals:{
Bunnie:function(){alert(‘Bunny’);},
Fish:function(){alert(‘Fish’);},
Bear:function(){
alert(‘A Bear Has A’);
HelloWorld.Animals.Fish();
}
}
}

Javascript Class Way:
Notice: Humm, this is nice, notice the fact that since everything is in a closure, we are able to retain scope. We don’t have to work down the heirarchy, just use the closes parent object to reference sub-objects. If you do lots of api calls which is what about 30% of code is, this can greatly enhance how clean code is.

HelloWorld = new (function(){
var hw = this;
hw.Animals = new (function(){
var animal = this;
animal.Bunnie = function(){alert(‘Bunny’);};
animal.Fish = function(){alert(‘Fish’);};
animal.Bear = function(){
alert(‘A Bear Has A’);
animal.Fish();
};
})();
})();

Classical Way:
Notice:Really, classical is getting worse here, and we have the same problem that the object literal has, as the fact that there is no retention of scope.

HelloWorld = function(){}
HelloWorld.Animals = function(){};
HelloWorld.Animals.Bunnie = function(){alert(‘Bunnie’);};
HelloWorld.Animals.Fish = function(){alert(‘Fish’);};
HelloWorld.Animals.Bear = function(){alert(‘A Bear Has A’);
HelloWorld.Animals.Fish();
};

• Lets say that we wanted to create a private field in a domain object.

Object Literal Way:
Its not possible to do it.

Javascript Class Way:
Due to the fact that sub classes are defined in the parent class scope is inherent, and privates become easy to achieve. Privates only exist in the confines of a { and }, so a parent object could never access a child private.

HelloWorld = new (function(){
var hw = this;
var privateHello = ‘Hello World’;
hw.Animals = new (function(){
var animal = this;
animal.Bunnie = function(){alert(‘Bunny’);};
animal.Fish = function(){alert(‘Fish’);};
animal.Bear = function(){
alert(‘A Bear Has A’); animal.Fish();alert(privateHello);};
})();
})();

Classical Way:
You can define a private variable in the HelloWorld Object, but due to scope issues you can’t share it with any other object.. *sigh*.

HelloWorld = function(){var privateHello = ‘Hello World’;}
HelloWorld.Animals = function(){};
HelloWorld.Animals.Bunnie = function(){alert(‘Bunnie’);};
HelloWorld.Animals.Fish = function(){alert(‘Fish’);};
HelloWorld.Animals.Bear = function(){alert(‘A Bear Has A’);HelloWorld.Animals.Fish();
};

Hummm whenever we start to do anything complexed, a clear winner is beginning to emerge here. Lets continue, and try some other common programming practices. How about we try out constructors. … More on this a bit later.. getting late…

Alpha Edition!, e-mail spelling/grammer/topic suggestions to mattprokes@gmail.com

The Professional Developer Series
Volume 2, Web Development
Chapter 1.4 Web Development Trends
Page: #22

Javascript, now more then ever is becoming of increasing importance. For those companies that want to deliver rich platform agnostic applications out to their users, javascript is the only way to get it done. The best part is, possibilities that javascript opens up are endless and its this authors belief that we will be talking about the langauge for years and years to come. So what are some of the javascript based trends that we are seeing today, and will be seeing in the future.

Trend 1:  Stop delivering dynamic server generated web content. As webapplications progress more and more companies are finding out that really all they need a server to deliver these days is web application code, and data. Javascript is slowly trending toward being server technology agnostic, especially with the advent of json it no longer matters where the data is coming from as long as there is data, thats all that matters (data driven applications). Pretty much all web applications these days can be delivered as flat .html files.

Trend 2:  Rich Browser Applications. As web applications evolve we are finding that in many cases you can save the webapplication to the desktop and use it regardless of wheither it is online or offline! Basically allowing a person to use a browser based application as a replacement for a regular desktop application, all that is required is a javascript based browser. Technologies such as Google Gears, Dojo, and a few new ones presented in this book allow such applications to exist. We will be building a few rich browser applications throughout this book.

Trend 3:  Data Mashed Web Applications. Need to get data from many locations to build and analyse useful information? This is what data mashing, and data mining is all about. You can use javascript these days to build dynamic map content, and create collaborative information sets for your users. Information services such as Yahoo Pipes, Popfly, and Semantic Web Pipes .

Trend 4: Intelligent Web Applications. When people think artificial intilligence, often I see thoughts conjured of a computer that knows all, sees all, and can communicate fluently with humans, solving all the worlds problems. In reality AI won’t probably be something that arises from the ashes of a genius programmer that created the next HAL system. No, what is most likely to happen is the development of a system which is asked questions, and is able to dynamically analyse correct sets of existing data and come up with a solution. Computers’ intelligence based on the current state of technology is completely dependent on what we contribute to them. We often call this computational analytics, today javascript is often used to drive the next generation of intelligent web based applications.

Trend 5: Collaborative Media Applications/Groupware. This set of javascript applications is specifically targeted at collaborative media, and and communication. Applications such as google docs, facebook, myspace, youtube, and more. All of these media companies provide javascript based collaboration. Probably the most striking would be google docs collaboration tools that allow you to write a document in a tool similar to word, but it also allows several people to write a single document all at one time! Another example is chatting on facebook, you can communicate with your friends right from the website using a javascript based chat application. I expect in the future to only see more and more of these applications as their popularity increases.

Trend 6: Javascript Frameworks. Javascript as a language and native api is actually very small compared to other langauges out there. While very small, the functionality the langauge provided was very powerful. So what people started doing is building up API’s around the langauge which they could leverage to make their job of programming more easy. Frameworks were a great innovation for the language, and it is very likely that people wouldn’t think to build the collaborative applications they do today with javascript if great frameworks for the language didn’t exist. A good list of frameworks are JQuery, Dojo, YUI, MooTools, and many others. Often libraries attempt to make up for javascripts cross platform compatibility issues, and also try to make the language more easy to code.

Trend 7: Taking javascript beyond the web. I don’t know how many people know this but firefox is actually coded in javascript. Now you may sit back and wonder how can that be? The number of non-web-browser technologies based on javascript  is actually increasing, and since it is the most popular programming language in the world many organizations are beginning to offer javascript apis for their products. See, just like xml, there are many technologies out there that understand the javascript language. Projects such as firefox, linux gnome, jaxer, and many others are beginning to implement these “javascript interpreters” and thus are able to extend their applications using the javascript langauge.

Trend 8: Javascript is becoming the new duct-tape of the web. Like Perl was a few years ago for getting things done, javascript is beginning to increasingly replace that role, expect that trend to continue as we me toward a more and more online world.

[digg=http://digg.com/programming/Create_Webapplication_Templates_From_Scratch]I am actually a very strong believer in template technologies, and the objective of this document will be to layout a plan of how you can implement webapplication templates using jquery.

Step 1) Create The Template
I am just going to start off with something simple such as:

<div id=”Blah-Application”>
<div id=”Blah-Application-Header”>
<div class=”header”>Head</div>
</div>
<div id=”Blah-Application-Record”>
<div class=”record-clone”>
<div class=”id”></div>
<div class=”user”></div>
<div class=”date”></div>
</div>
</div>
</div>

Step 2) Bind The Data
var data = [{id:21341,user:'mprokes',date:'12/13/08'},{id:2134234,user:'pants',date:'10/12/08'}]

Populating the records.
var clone = $(‘.record-clone’)
function populate(){
$(data).each(function(){
var cloned = clone.clone();
cloned.addClass(‘record’);
cloned.find(‘.id’).val(this.id);
cloned.find(‘.user’).val(this.user);
cloned.find(‘.date’).val(this.date);
$(‘#Blah-Application-Record’).append(cloned);
});
}

Getting the records.
function getRecords(){
var records = [];
$(‘#Blah-Application-Record .record’).each(function(){
records.push({id:this.find(‘.id’).val(),user:this.find(‘.user’).val(),date:this.find(‘.date’).val()})
});
return records;
}

Step 3) Tagging and sorting the records.
function tagDefaults(){

$(‘#Blah-Application-Record .record’).each(function(){

if(this.find(‘.user’)==’mprokes’ || this.find(‘.user’)==’roger’){
this.addClass(‘default’);
//or you could also change/set attributes, etc. As well as sorting.
//since you get back a list of nodes, you can push, pop,slice, etc those
//nodes from the list, and then re-append the list of nodes again to #Blah-Application-Record
}

});

}

function getDefaults(){
return $(‘#Blah-Application-Record .default’);
}

Conclusion, Creating a view; for a model view controller (MVC) does not need to be hard, it can actually be very easy and straight forward. To simplify your webdevelopment sometimes it is the only way to go. Next time your sit down and write a webapplication try it out, you may be surprised how nicely it works.

~Your Friendly Webdeveloper
Matt Prokes

[digg=http://digg.com/programming/Why_I_am_on_the_fence_about_jbind_for_jquery] DEJA VU?!?! doesn’t the dom already do this?

So then why are we doing this modeling in jbind?

The history, I was recently introduced to a tool for binding data to a markup template called jbind. While in theory its not a bad idea I get this weird feeling we shouldn’t be using it, ESPECIALLY if you are using jQuery and even more funny its a jQuery plugin .

So let me explain the reasoning for this feeling, in html we have these neat things called classes. Classes allow you to effectivly “tag” markup as being a “grouping” of data. From there you simply just execute a property selector query and wala you got your data. Its very nice from a WYSIWYG perspective. Now jbind is mainly for automatic binding of data to a templated record set, and then the syntactical niceness is created around each record upon population.

That is great and all, except there is a requirement to generate a type of in-script model-view combo. jBind functionality can be effectivly implemented without the requirement of the library if perhaps a bit better judgement is used during the creation of the webapplicaton.

So to prove my point, lets give an example of what jbind would be best applied. A tableset of data.

This effectively says create a parent div, create 2 children, and inject the value of blah and cool into those children. What happens is jbind will runs through all nodes, and identify where to put data. While this is great if you are doing nothing with the data and the nodes that you are binding, it sucks for all other cases.

This is because you need to create a sort of “event callback” if you need to do more to the node upon the data injection, and then do even more work just to pull the data back out again, modify it. We are not even talking about adding events to the dynamically created nodes, which also will require more work.

What if we did this:

What happens here is you var x = $(‘.parent:first’).clone(), and inject the data into the template like this, x.children(‘.blah’).text(value); and x.children(‘.cool’).text(value);

Finally appending it to $(‘.parent:first’).parent.append(x);

This is nice because you do not need event callbacks on node creation; the data manipulation, as well as binding of events to the created nodes can happen on the clone as always. You also have html that has classes on it, and can later be queried for further manipulation, or just seeing what data is within that scope. The idea from what I percieve as far as jbind goes is to remove the need for classes, why, I don’t know classes are great.

So to conclude, I am not saying jBind is bad really, it is more efficient if you want to spit some json data out in the wild without doing anything extra. Prototyping for instance may be served well with this solution. Though I would argue that if you are not doing anything other then that, then maybe you shouldn’t be doing your stuff in js in the first place and maybe just do it through the back end. On the other hand, if you are going to need to modify the data, add events to dynamically created nodes, etc..

Then it is likely jbind will not be for you, and will just end up being more work then it is worth, since dom has a solution to this that is already pretty good, and much lighter and flexible then anything jbind is offering at the moment in many respects.

For those that do not yet know, I work for internet broadcasting. An awesome company out in st. paul, minnesota. While working on some very large scale webapps, an annoyance came to light. Namely coding in styling directly to your webapplication.

Why is this a big no-no?

Well when css came out the big great thing about it is that people had their own language to specify, and seperate look and feel configurations, as well as the ability to take action on specific events like hover. This was a great idea simply because all this data was configuration and NOT code. Also it allowed people like designers to have a single point to go to if they wanted to make a red box green.

CSS was and still is great. So what happened?

DHTML happened. While a great idea dhtml put styling back into code (namely javascript), and css never adapted for this change. Stuff like webanimations started happening and there was no way to put that into css because css isn’t extensible in that way. So what did we as developers do? Well the only thing we could, we tried to put as much in css, and all the dynamic stuff got crammed into code!

But I have a solution for those of you that work on large scale webapps.

Introducing CSSPlusPlus.js!

What is it?: CSSPlusPlus.js allows you to in-a-way extend CSS through custom pseudo classes and property’s!
- Allowing for you to cram all sorts of configuration information, animation info and styling into one easy to use location. Think spring (sorta) for webapplications.

Ok Enough Talk Lets Roll To A Useful Example.

First you need to go out and get CSSPlusPlus.js, its under the MIT license so no worries.
You can find it here: http://www.webactivelabs.com/js/CSSPlusPlus.js

I know the namespace is pretty generic, feel free to rename it if you need to. Anyway Lets start off by creating a simple webapplication for creating boxes. I will also be using jquery for this example to show a practical use, in animation.

What it would look like:
BoxCreator.html
BoxCreator.js

Excellent, humm, if we investigate the box creator you will notice that I have coded in an animation height and width to expand out to, as well as some coloring information, and even a error message.

Humm thats alot of domain specific data coded directly in, what if this was a large scale application, how would we find this in the future? Surfing the code? Find? There must be a better way. Well lets start off by taking out all width and height information. For boxes.

What it would look like:
BoxCreator.html
BoxCreator.js

//Add a pseudo class to listen for!
CSS.addPseudoClassListener(‘boxcreator’,createBoxStyle);

BoxCreatorConfig.css.js

//The CSS parser at work for a custom pseudo-class :boxcreator
CSS.parse(‘.box:boxcreator {height:30px; width:400px; color:purple;}’);

Mmmmm, thats much better, humm.. but we still have some error messages. Lets say that we have a large amount of error messages that we want to keep track of, or we just other configuration data. Humm what if the designers do not like the wording of the messages? Well lets pull those out to, and send the designers the file and go have some coffee.

What it would look like:
BoxCreator.js

BoxCreatorConfig.css.js

//Any number of rules can be defined in a single parse.
CSS.parse(
‘.box:boxcreator {height:30px; width:400px; color:purple;amount:5;}’,
‘*:error{error123:crazy beefy cow!;}’
);

Alright, time to show the company the wonderful box creator that we made, lets go out and take a look at it.

BoxCreator.html

Thats all there is to it!

Whats actually happening here? I am not advocating that you dump all of your css into this tool, though styles that you do not listen for actually flow through the system and get spit out as an inline style tag. The custom css that you are defining is NOT actually real css, its just recognized by a simple glorified css parser that looks for property’s and pseudo classes. In a way it is similar to a sax parser, only for css instead. There is no magic, more like cloak and dagger.

If its a pseudo class listener:
The entire property’s list gets turned into json object and sent to the callback, as well as the selector that was defined for that pseudo class.

If its a property listener:
Just that property gets sent to the callback along with the selector, the rest of the property’s not being listened on get sent to a inline style tag, as standard css.

The Good:
Its just a glorified parser, but the designers won’t know the difference, and its efficient (I am all for tricking designers). Infact if you define custom css and do not listen for it, then it will flow through the system and get spit out in the style tags and the browser simply won’t do anything with that css. Many of you will say whats the point of this, I can create property files right now as a json object.

Yet that will require designers to learn a new language, as well as possibly breaking your app by coding native js. Also the syntax and the readability of this method is superior to that of a json property file in the context of applying a custom css action. Lastly, the pseudo class can be used on any selector, its not a one shot deal.

Example:
#button1:fadeButton {fade-to:green;}
#button2:fadeButton {fade-to:red;}

This method could also be used to fix things like hover, without hacking like crazy. Its in javascript.. but if you are designing a webapp, then that webapp is in javascript anyway. Plus you can be sure you won’t need to find the next greatest css hack when vendors decided to release the next greatest and latest. I advocate coding as much as you feel certain will be supported now, and in the future in css. Then maybe keeping your life simple, and using the parser for the rest .

The Bad:
There is a very small amount of parsing happening, I emphasize small. If you compare the amount of processing used for this method of specifying property’s; I would compare it to 1/1000th of the processing required to cause a animation to happen in the browser, and it only happens once. For those of you that are speed demons, and have to squeeze every last bit of performance out of your code then this might not be the solution for you. But in my case its a perfect fit. Secondly,

I wouldn’t on a regular basis define standard css through this interface unless you know what you are doing, or the definitions are placed in the document head. The reasoning is that your styling won’t be placed in the document until the script loads keep in mind. So IF you place your script tag AFTER your html structure, you will see the action of the standard css being applied to that structure once the js is loaded, which again is AFTER the html structure is displayed.

Anyway, use it at your own discretion, and have fun.

Your Friendly Developer,
~Matt Prokes

So today I am reading through this book pro-javascript design patterns, excellent book by the way! I had come upon chapter 2, which was an excellent explanation of interfaces. One thing that concerned myself is that the book states that it is impossible to create enforceable interfaces in javascript. I pondered that for a bit, as far as what interfaces really are. If you look at interfaces from the perspective of java, then for the most part they are types, with a specified subset of methods for a class instance.

Thinking in those terms, I sat back and pondered the problem again, sooo all I need to do really to create interfaces that are enforceable in javascript would be to separate the concept of an interface from a class all together and make it a class its self! WALA! True first class interfaces in javascript!

UML Diagram

So lets see what this new found idea looks like! Here is my interface class that makes it all work.

Interface.js

You can think of interface as linking everything together, but what would a TestInterface look like?

TestInterface.js

Take note, that the interface its self is already implementing Interface.js in a sort-of way! There are two required methods getInterfaceName() and setUpInterface() that need to be implemented otherwise Interface.js will complain loudly!

The basic idea here is that setUpInterface recieves a closure, that is able to access the implementing object, all the TestInterface needs to do is call that method with the same attributes it recieves. It does this by passing in the name of the method into the closure, and then executing the returned function with the same attributes recieved by the method; and return it, SIMPLE!

You can see this happening here:

return inspector(‘testMethod’)(x,y,z);

So now that we have an interface for our class, what does a javascript class have to do to implement this interface?

TestObject.js

The actual implementation of the interface happens here: new Interface(this, new TestInterface());
Wow! thats easy! But what happens when the class doesn’t implement all the methods as this one does?

Well lets find out, if you could place all these scripts in a javascript shell, lets test out a few things.

//Create a new TestObject();
TestThis = new TestObject();

//Lets cast our object to a type of ‘TestInterface’
CastedTestInterface = TestThis.cast(‘TestInterface’);

Don’t take my word for it, here is a FULL WORKING EXAMPLE!

Now if you inspect CastedTestInterface you may notice that it is just an instance of the interface you created! Keep in mind though that it also holds a closure to the object it was casted from.

Lets try executing a method:

CastedTestInterface.testMethod(1,2,3);

Whoa! it worked!
Lets try executing another method specified by the interface:

CastedTestInterface.testMethod2(1,2,3);

Opps, we get an error because this method does not exist! We better fix that, humm but this means that the interface is working!

Long story short, if a method you call from a cast is missing from the object; you will be alerted when you call the method, an error will be thrown, and you scolded for doing such a horrible thing! To be honest, this method is 1/2 of an abstracted class and 1/2 of an interface, an {interstraction}?!?!

This is because most interfaces specify that they can not have implementation details in them, but ours do. On the other hand this is not a abstracted class! Because abstracted classes are extensions of the original, when clearly this type of OOP not an extension, but a subset. Hope you enjoyed the tutorial on how to create interfaces .

Commenting Your Code
Comments will always be an important part of programming; they are often used to describe whats going on in your code, and even for automatically generating documentation.

There are two styles of comments:

• //Single Line

• /*
  Multi
  Line
  */

Some issues with multi-line comments:

Since multi-line comments end with */ this means that you may never include a */ within the body of the comment.

example:

/*An error is caused when I use a */ as you can see.*/

Reserved Words
Reserved Words are used by the javascript programming language to identify programming structures, and execute instructions based on those structures.

There are 59 reserved words identified by the language as follows:

abstract, boolean, break, byte, case, catch, char, class, const, continue, debugger, default, delete, do, double, else, enum, export, extends, false, final, finally, float, for, function, goto, if, implements, import, in, instanceof, int, interface, long, native, new, null, package, private, protected, public, return, short, static, super, switch, synchronized, this, throw, throws, transient, true, try, typeof, var, volatile, void, while, with

I am also including (undefined, NaN, and Infinity) as being reserved, though they serve a different purpose of describing data rather than structure.

Some Notes On Reserved Words:

• Not all reserved words are used by the langauge, so you will only need to memorize the functionality of a small subset.
• Do not use reserved words to name object literals, properties, variables, parameters, or any other programming structure for that matter.

Numbers
Numerical values are and will continue to be used throughout your development career. Thus I suggest that you become familiar with the properties of javascript numerical values.

Numbers Are:

• Wrapped up as objects when inspection is required, but are treated as primitives!
• 64bit
• Represented by a single object type (meaning an integer value of 1 is also 1.0 and a boolean value of true).
• Covers classic number types such as int, float, boolean, double, and long

Integers are represented by a numerical value, but are not followed by a decimal place.

• 123

Decimals are represented by numerical values containing a decimal place.

• 123.456

Exponents are represented by a numerical value followed by an e and a positive or negative decimal placing.

• 123e-3 (represents .123)

Negative numbers are represented with a – followed by a numerical value.

• -123

Infinity is represented by numbers greater than 1.79769313486231570e+308

Strings
Strings represent data specifying a set of characters. Strings are also the most commonly used data for most languages. Javascript is no exception, whether creating javascript object literals or validating form data you will find that strings pose an important role in your programming career. Strings are objects and contain important functions for manipulation and objects details.

Strings can be specified through two methods:

• “This is a string!”
• ‘This is a string!’

Why two ways of writing strings?
This is because at the time javascript was created, it was not an uncommon perception that it may be integrated tightly with html. So if you have a tag that uses an onclick=”alert(“oops”)” this would escape the parameter before needed. This may be rectified  by escaping the quotes using \” but it is often more easy to just use a single ‘ as seen here onclick=”alert(‘yeey’)”. The duality of quoting often cancles its self out very nicely, so as to not impede programming.

Some other notes about strings:

• Strings are immutable
• Concatination is done with a + operator (ex: “hello “+”my “+”name “+”is “+”matt “)
• Strings are objects
• You may escape something within a string using a \ (ex “I want to see a \\ or a \” “)

Javascript, the worlds most popular programming language is also the worlds most mis-understood language. The purpose behind these posts is to clear up somewhat the facilities of javascript, and make clear what this powerful language has to offer. I plan on providing clear examples, with no fluff. Enjoy.