DotNetWise©

Tuesday, November 17, 2009

Closure Compiler Externs Extractor

Many programmers are trying to use the Google Closure Compiler in their own applications but quickly they are hitting a wall: suddenly their third party APIs got renamed and the application doesn't work anymore, because they did not define the correct Externs!

If you already know what Externs are you can go directly to the Closure Compiler Externs Extractor example.

Closure compiler is an amazing tool if it is used as it was designed. The difference between it and other tools is that it really compiles the javascript and not just "minify" like YUI Compressor or Ajax Minifier does.

One of the concepts behind is that we can rename all the symbols and not just the local variables.
Nice to hear that, but this is very bad for the current javascript pieces of code that were not written with Closure Compiler's rules in mind.

i.e.

MyApp.MyNamespace.MyObject.MyMethod = function() {...}
var o = MyApp.MyNamespace.MyObject.MyMethod();
gets compiled into
b.c.d.e = function() {...}
var a = b.c.d.e();


Well that is very good if I own the source code of MyMethod, so it will also be renamed along the road to the same short name e.
However, if I would like to make this code available for other people to use into their application as a plugin - it might not be that good, as on every compilation I would get a different method name.
Google's solution is to export your symbols.
Yeah, I can do that, because it's my code, right?


MyApp.MyNamespace.MyObject.MyMethod =
window["MyApp"]["MyNamespace"]["MyObject"]["MyMethod"] = function() {...}


This would still compress my code on all the location where it is used (as above), but will also make it available of other users to use it with public friendly names.

Well, this is good, but is very bad if I need to use an external API that is maintained by a third party.
In that case Google's solutions is to use an Externs file on the compilation.

An externs file is basically a javascript file that instructs the closure compiler about some symbols that are defined in a third party code that it is not aware of.

i.e. If I'm using jQuery, but I can't include it into my compilation, because it is already used by other users on my site
- and jQuery is not yet friendly with the closure-compiler
- and I don't want to have two jQuery files on my site - one compiled and one not
I could define the externs I'm using in my compiled code like this:


var jQuery, $;
$.fn = jQuery.fn = {
bind: function() {
},
trigger: function() {
},
prepend: function() {
},
show: function() {
},
hide: function() {
},
append: function() {
}
};


All good, but I don't know all the public methods/properties of the APIs I'm using! Nor I want to waste time to write externs for each and every piece of code for all the extern APIs I'm using!

So, I have written a small example of how to extract all the properties / methods of a javascript object as externs.

Please leave a comment if this helps you or if you have suggestions to improve it.

Tuesday, November 10, 2009

EasyXDM, the best Cross-Domain XSS / XDM javascript solution

There are tons of posts and articles about cross-domain communication and Same Origin Policy limitations on the web, but none of them are providing you a real browser-transparent solution.

After I dug over a month in this area, I have finally found the best solution!
It is called EasyXDM, and I really want to thank to oyvind for it.

I'm not going to write just yet of how easy can it be used but you can read here

There was a bug on the Tests suite that was crashing Google Chrome and Safari browsers but I have fixed it here. Be aware that the tests are forced to run in all the transports and some of them are expected to fail in certain browsers. However all of them should pass on the "Best Transport" tests suite.
[Update: Oyvind has also updated the test suite here]

For those who don't want to spend a month doing the research they can start with these resources:

http://www.slideshare.net/mehmetakin/ajax-world
http://www.slideshare.net/kuza55/same-origin-policy-weaknesses-1728474
http://easyxdm.net/
http://kinsey.no/blog/index.php/2009/08/20/easyxdm/
http://msdn.microsoft.com/en-us/architecture/bb735305.aspx
http://code.google.com/apis/gears/gears_faq.html#crossOriginWorker

Enjoy cross domain re-usable applications!

Wednesday, November 4, 2009

Exclude a folder from solution explorer in VS2008 website

In any project of Visual Studio.Net environment excluding a folder is very simple. We just need to right click on the folder and select Exclude from Project. But in Website of Visual Studio.NET it is not that easy to hide a folder and also there is no direct way to exclude a folder from Website.

The easy way to exclude an unwanted folder from a website is to physically delete the folder from the website structure. But what if you should not delete the folder from the website structure? Here is a simple trick to hide(not deleting) a folder from Visual Studio.NET editor as well as from Visual Source Safe.

Set Hidden attribute for the folder which you want to exclude from project, and the refresh the Website(project) in Visual Studio.NET Solution Explorer. Here are the detailed steps to be followed

1. Open Windows Explorer
2. Locate the physical folder of your website
3. Right click the folder which you want to exclude, and then select Properties
4. Check the Hidden attribute
5. Click the Refresh button in the Visual Studio.NET Solution Explorer

Using this simple trick you can even hide files of a website from Visual Studio.NET environment.

Thanks for TechDreams for letting us know this easy but very useful trick!
 
Blog powered up by Blogger