RSS

Category Archives: Javascript / DOJO

Javascript Compiler

source : http://www.virtualpromote.com/tools/javascript-encrypt/
javascriptcompiler

 
Leave a comment

Posted by on August 17, 2009 in Javascript / DOJO, Web

 

Tags: ,

Web Development Resources

Very useful links for Web Development

http://vinaytech.wordpress.com/web-dev-links/

 
Leave a comment

Posted by on July 24, 2009 in Javascript / DOJO, Mashups, Web

 

Tags: , , , , , , , , , , , , , , , , , , , , , , , , , , , ,

Closures and IE Circular References

the below nice article is from http://siteexperts.spaces.live.com/Blog/cns!1pNcL8JwTfkkjv4gg6LkVCpw!338.entry

Memory Leak Detection Tool

==================================================================================

A little tip for you advanced Javascripters…

First, if you are not familiar with JavaScript closures, I highly recommend you read up on them. They are extremely powerful.  However, they are also very unforgiving in they quickly generate memory leaks.  IE has an issue where it leaks memory when a circular reference is created between a com object and a javascript object.  In IE, the DOM is implemented via com.

So looking at a simple closure (noticed the nested function):

function DoThis()
{
var el = document.createElement(“div”);
el.attachEvent(“onclick”,DoThis);
function DoThis()
{
alert(“clicked”);
}
}

creates a new scope and generates a circular reference that will leak memory in IE. This memory is not reclaimed until the browser closes. The simplest solution is to pretend there is no garbage collector for objects and make sure you always clean-up after yourself.

Fixed version:
function DoThis()
{
var el = document.createElement(“div”);
el.attachEvent(“onclick”,DoThis);
window.attachEvent(“onunload”,Cleanup);
function DoThis()
{
alert(“clicked”);
}
function Cleanup()
{
el.detachEvent(“onclick”,DoThis);
window.detachEvent(“onunload”,Cleanup);
el = null;
}
}

What makes closures interesting?

If you don’t know, I am going to help you figure it out on your own. Let’s take a simple example using the setTimeout method.

Today, it is difficult to pass rich state to a function called on a timer. The setTimeout method takes two arguments, a function to execute, and how long to wait before executing it.  For example:

function twoSeconds()
{
alert(“Two Seconds have past”);
}
setTimeout(twoSeconds,2000);

Now, unfortunately there is no way to send arguments to that function (and before the JavaScript experts jump in, I do not believe serializing the values to a string is an option – most scenarios I deal with require object references)

Today, the typical (and hard to maintain) approach is to store some state in a global:

var objState = {name:”foo”,message:”Hi”};

function twoSeconds()
{
alert(objState.message);
}
setTimeout(twoSeconds,2000);

I hopefully don’t have to explain why that is bad :-).

Now let’s try using closures:

function twoSeconds(arg1,arg2)
{
function Execute()
{
alert(arg2);
}
return Execute;
}

setTimeout(twoSeconds(“foo”,”Hello World”),2000);

Look closely at the above code.  Notice that the function twoSeconds returns a function pointer to the nested Execute function (which creates a new scope chain). After two seconds, the Execute function will be called.  When Execute is called, it has access to the arguments up the entire scope chain (so arg1 and arg2 are accessible).  Each time you call the twoSeconds function, a new and independent scope chain is created.

Below is an alternative approach that performs the setTimeout directly in the twoSeconds function:

function twoSeconds(arg1,arg2)
{
function Execute()
{
alert(arg2);
}
setTimeout(Execute,2000);
}

twoSeconds();

If you step back and look at the bigger picture, you will notice that closures open up the door for encapsulating private functionality and provide a very valuable approach for avoiding the mass creation of global variables.

function myObject()
{
var privateVar=1;
var privateVar=2;
function PrivateMethod()
{
// Do Something;
}
this.publicMethod = function()
{
PrivateMethod();
}
}

var newObj = new myObject();

=================================================================================

 
1 Comment

Posted by on February 24, 2009 in Javascript / DOJO, Web

 

Tags: , , , ,

JQuery4GWT

Jquery4Gwt is an adaptation of jquery to GWT developper.

Sami Bessaies BLOG – Tutorial

  • Demo
  • Getting Start
  • Java Doc
  • Sample
  • Screenshot

    jquery4gwt1


     
    Leave a comment

    Posted by on February 19, 2009 in GWT, Javascript / DOJO, Web

     

    Tags: , ,

    JavaScript – Most Misunderstood Programming Language

    JavaScript, aka Mocha, aka LiveScript, aka JScript, aka ECMAScript, is one of the world’s most popular programming languages. Virtually every personal computer in the world has at least one JavaScript interpreter installed on it and in active use. JavaScript’s popularity is due entirely to its role as the scripting language of the WWW.

    Despite its popularity, few know that JavaScript is a very nice dynamic object-oriented general-purpose programming language. How can this be a secret? Why is this language so misunderstood?

    The Name

    The Java- prefix suggests that JavaScript is somehow related to Java, that it is a subset or less capable version of Java. It seems that the name was intentionally selected to create confusion, and from confusion comes misunderstanding. JavaScript is not interpreted Java. Java is interpreted Java. JavaScript is a different language.

    JavaScript has a syntactic similarity to Java, much as Java has to C. But it is no more a subset of Java than Java is a subset of C. It is better than Java in the applications that Java (fka Oak) was originally intended for.

    JavaScript was not developed at Sun Microsystems, the home of Java. JavaScript was developed at Netscape. It was originally called LiveScript, but that name wasn’t confusing enough.

    The -Script suffix suggests that it is not a real programming language, that a scripting language is less than a programming language. But it is really a matter of specialization. Compared to C, JavaScript trades performance for expressive power and dynamism.

    Lisp in C’s Clothing

    JavaScript’s C-like syntax, including curly braces and the clunky for statement, makes it appear to be an ordinary procedural language. This is misleading because JavaScript has more in common with functional languages like Lisp or Scheme than with C or Java. It has arrays instead of lists and objects instead of property lists. Functions are first class. It has closures. You get lambdas without having to balance all those parens.

    Typecasting

    JavaScript was designed to run in Netscape Navigator. Its success there led to it becoming standard equipment in virtually all web browsers. This has resulted in typecasting. JavaScript is the George Reeves of programming languages. JavaScript is well suited to a large class of non-Web-related applications

    Moving Target

    The first versions of JavaScript were quite weak. They lacked exception handling, inner functions, and inheritance. In its present form, it is now a complete object-oriented programming language. But many opinions of the language are based on its immature forms.

    The ECMA committee that has stewardship over the language is developing extensions which, while well intentioned, will aggravate one of the language’s biggest problems: There are already too many versions. This creates confusion.

    Design Errors

    No programming language is perfect. JavaScript has its share of design errors, such as the overloading of + to mean both addition and concatenation with type coercion, and the error-prone with statement should be avoided. The reserved word policies are much too strict. Semicolon insertion was a huge mistake, as was the notation for literal regular expressions. These mistakes have led to programming errors, and called the design of the language as a whole into question. Fortunately, many of these problems can be mitigated with a good lint program.

    The design of the language on the whole is quite sound. Surprisingly, the ECMAScript committee does not appear to be interested in correcting these problems. Perhaps they are more interested in making new ones.

    Lousy Implementations

    Some of the earlier implementations of JavaScript were quite buggy. This reflected badly on the language. Compounding that, those implementations were embedded in horribly buggy web browsers.

    Bad Books

    Nearly all of the books about JavaScript are quite awful. They contain errors, poor examples, and promote bad practices. Important features of the language are often explained poorly, or left out entirely. I have reviewed dozens of JavaScript books, and I can only recommend one: JavaScript: The Definitive Guide (5th Edition) by David Flanagan. (Attention authors: If you have written a good one, please send me a review copy.)

    Substandard Standard

    The official specification for the language is published by ECMA. The specification is of extremely poor quality. It is difficult to read and very difficult to understand. This has been a contributor to the Bad Book problem because authors have been unable to use the standard document to improve their own understanding of the language. ECMA and the TC39 committee should be deeply embarrassed.

    Amateurs

    Most of the people writing in JavaScript are not programmers. They lack the training and discipline to write good programs. JavaScript has so much expressive power that they are able to do useful things in it, anyway. This has given JavaScript a reputation of being strictly for the amateurs, that it is not suitable for professional programming. This is simply not the case.

    Object-Oriented

    Is JavaScript object-oriented? It has objects which can contain data and methods that act upon that data. Objects can contain other objects. It does not have classes, but it does have constructors which do what classes do, including acting as containers for class variables and methods. It does not have class-oriented inheritance, but it does have prototype-oriented inheritance.

    The two main ways of building up object systems are by inheritance (is-a) and by aggregation (has-a). JavaScript does both, but its dynamic nature allows it to excel at aggregation.

    Some argue that JavaScript is not truly object oriented because it does not provide information hiding. That is, objects cannot have private variables and private methods: All members are public.

    But it turns out that JavaScript objects can have private variables and private methods. (Click here now to find out how.) Of course, few understand this because JavaScript is the world’s most misunderstood programming language.

    Some argue that JavaScript is not truly object oriented because it does not provide inheritance. But it turns out that JavaScript supports not only classical inheritance, but other code reuse patterns as well.

     
    Leave a comment

    Posted by on October 14, 2008 in Javascript / DOJO

     

    Tags: ,

     
    Follow

    Get every new post delivered to your Inbox.

    %d bloggers like this: