Web Info & Tutorials

February 7th, 2008

DJANGO TEMPLATE LANGUAGE IN JAVASCRIPT

I am learning at lot at the Dojo Developers Day one. Whenever I met Dojo folks I get the impression that there are 55 gems in the library that I have no idea about!

One of them is Neil Roberts implementation of the Django template language in JavaScript.

His work lives in dojox.dtl and you can check out a simple demo that renders, and rerenders a page with new content as you add it:

HTML:
<html>
<head>
        <title>Demo using dojox.dtl._Templated</title>
  <script type="text/javascript" src="../../../dojo/dojo.js"
                djConfig="isDebug: true, parseOnLoad: true">
</script>
  <script type="text/javascript" src="../../../dijit/dijit.js"></script>
  <script type="text/javascript">
        dojo.require("dojox.dtl._Templated");

        dojo.declare("Fruit", [dijit._Widget, dojox.dtl._Templated], {
                oldRepl: "some value for testing the old style template substitution",
                _dijitTemplateCompat: true,
                items: ["apple", "banana", "orange"],
                keyUp: function(e){
                        if (e.keyCode == dojo.keys.ENTER) {
                                var i = dojo.indexOf(this.items, e.target.value);
                                if (i != -1){
                                        this.items.splice(i, 1);
                                } else {
                                        this.items.push(e.target.value);
                                }
                                e.target.value = "";
                                this.render();
                                dojo.query("input", this.domNode).forEach("item.focus();");
                        }
                },
                templateString: '<div><input dojoAttachEvent="onkeyup: keyUp"/><ul>{% for item in items %}<li>{{ item }} ${oldRepl}</li>{% endfor %}</ul></div>'
        });

  dojo.require("dojo.parser");
  </script>

        <body>
                <div dojoType="Fruit"></div>.
        </body>

</head>
</html>
 

You can also see another interesting example which is a blog view. Take a view source on that puppy.

February 7th, 2008

IWEB GROUP INCREASES LOAN FACILITY

IT stock bourgeois iWeb Group declared on weekday it has accumulated its existing disposition artefact with the Bank of metropolis . via TheWHIR.com

February 7th, 2008

JAVASCRIPT LIBRARY LOADING SPEED

John Resig has analyzed JavaScript library loading speed by looking into the recent PbWiki testing results.

He delves into the fact that file size != speed and puts out the simple formula:

Total_Speed = Time_to_Download + Time_to_Evaluate

We also seem to obsess about packing and minification, where it often does give us that much since the act of gziping the data often does enough. Thay being said, if you have a lot of JavaScript it can certainly be worthwhile. It matters the most that the frameworks themselves (which are normally bigger than the app) play nice.

In fact, walk around your site with Firebug/YSlow and see if you have set your headers up correctly. After watching Steve Souders at work, it boggles my mind how many big sites are misconfigured (let alone small ones).

February 7th, 2008

JQUERY UI AND JQUERY ENCHANT ALPHA VERSIONS RELEASED TODAY

The jQuery UI team announced today the release of alpha versions of jQuery UI 1.5a and jQuery Enchant 1.0a! The projects aim to address the need for a strong set of UI controls and effects to complement the jQuery JavaScript library.

I'm very happy to announce the first alpha release of both jQuery UI 1.5 and jQuery Enchant 1.0 to all the adventurous guys out there. This is a huge update - the whole API has been standardized and updated, and many of the plugins have been completely rewritten. jQuery Enchant is the missing part of UI: A library completely devoted to rich effects. It already features all effects you know from scriptaculous/interface, as well as many more great additions: color animations, class animations and highly configurable effects.

Taking a much more cautious approach this time around, the team has made it clear that this is an alpha release which will go through further testing and has requested heavy community involvement to ensure solid libraries are released in a final version.

The code and demos for the two libraries can be found here:

jQuery UI:
http://jqueryjs.googlecode.com/files/jquery.ui-1.5a.zip
http://ui.jquery.com/1.5a/demos/

jQuery Enchant:
http://jqueryjs.googlecode.com/files/jquery.enchant-1.0a.zip
http://ui.jquery.com/enchant/1.0a/demos/

It's important to note that both jQuery UI and Enchant require the newly jQuery v1.2.3 which was released last night.
http://code.jquery.com/jquery-1.2.3.js
http://code.jquery.com/jquery-1.2.3.min.js
http://code.jquery.com/jquery-1.2.3.pack.js

February 7th, 2008

SECURITY FOCUS: JAVASCRIPT GLOBAL NAMESPACE POLLUTION

Security should always be a concern when developing client-side applications as time and time again, sites have been compromised by a lack for forethought into how users, especially malicious ones, interact with your site. GNUCitizen.org is an excellent site for staying abreast of new security exploits and the team constantly pushes the boundaries of how to exploit systems in an effort to educate the public and make systems more secure.

GNUCitizen founder pdp just published an article on how to detect malware via the JavaScript global namespace:

Namespace pollution checks are very trivial to perform. The check should be performed from a safer location such as outside of the execution sandbox or somewhere on the top before and after the user input is taken into consideration. The check is very simple really. All that needs to be done is to compare the list of registered objects with the expected list of objects. If they defer, the namespace has been polluted by something. The check can be performed by a function similar to the one discussed by the Atom database over here:

LANGUAGE:
function walkJSON(j, c) {
    for (var i in j) {
        c(i, j[i]);

        if (j[i] instanceof Array || typeof(j[i]) == 'object') {
            arguments.callee(j[i], c);
        }
    }
}

He goes further to explain how malware authors could bypass this check using closures:

LANGUAGE:
(new function (window, document) {
    // [evil code here]
})(window, document);

This technique will safely execute malicious code without the need to worry about polluting the whichever namespace, as long as the evil code that is enclosed within the closure does not modify the window or the document objects. DOM manipulation is acceptable since no one is crazy enough to check for DOM changes. The document object is far more complicated and walking its is hard.

So here are some questions for the Ajaxian readers:

  • Is this a big issue that merits further attention?
  • If so, what can be done to mitigate the risks?
  • What are the scenarios in which something like this could occur?

Ajaxian readers are some of the best JavaScript developers out there and I'm positive that collectively, we can determine how high of risk factor this. Either way, it's always good to stay informed and I'm looking forward to seeing more JS security articles from GNUCitizen in the future.

February 7th, 2008

IPHONE CACHABILITY: WATCH YOUR WEIGHT

Reposted from devphone.

Wayne Shea and Tenni Theurer have continued their performance series by delving into the iPhone and its poor little cache.

I always wonder why the cache is so small. It is typical Apple to not allow an expert mode where you can tweak it. I would rather have a few less songs and have a large cache. But, Steve knows best ;)

The end result of the article is that you should follow this ideal rule:

Reduce the size of each component to 25 Kbytes or less for optimal caching behavior

Given that the wireless network speed on iPhone is limited and the browser cache is cleared across power cycle, it is even more important to make fewer HTTP requests to achieve good performance than in the desktop world. To reduce the number of HTTP requests, Safari on iPhone supports image map, CSS sprites, inline images and inline CSS images. Take advantage of the browser cache whenever possible. If an external component can be shared across multiple pages in the site, remember that each individual component has to be smaller than 25 KB to be cacheable. Also, the maximum cache limit of all components is 475 - 500 KB. Minify all the JavaScript, CSS and HTML. For components that aren’t shared across multiple pages, consider making them inline.

This of course is quite painful if you like to package JavaScript in One Large File for other performance reasons, or if you use a library that is larger than 25KB!

The iPhone can tell us a bunch of things about a site. If I go to TechCrunch for example, it drives me batty as it does a bunch of JavaScript to load in the CrunchBase widgets, and the iPhone keeps thinking it is loading. The blue bar keeps going, and the browser isn't as responsive. I hate those Crunchbase widgets :)