Garrick Cheung » Javascript

Smarty Debug with Firebug

Garrick — Thu, 16 Apr 2009 23:44:44 +0000

I use Smarty, a template engine, at work. One of the most awesome things about it is the debug window, where it can list all the templates being used and variables that are available.

Mike Horn shared with me how a user, named Hipska, created a Smarty debug template file that works with Firebug. I thought it was so awesome and decided to share it with you too, but with a slight tweak of my own.

The Code

Here’s the code. I’ll explain how it works right after.

{* Smarty *}
{* debug.tpl, firebug version by Hipska, tweaked by GarrickCheung *}
{assign_debug_info}
{if isset($_smarty_debug_output) and $_smarty_debug_output eq "html"}



    </span>Smarty Debug Console<span style="color: #009000;">
{literal}

{/literal}


 
Smarty Debug Console
 
included templates & config files (load time in seconds)
 

{section name=templates loop=$_debug_tpls}
    {section name=indent loop=$_debug_tpls[templates].depth}   {/section}
    
        {$_debug_tpls[templates].filename|escape:html}
    {if isset($_debug_tpls[templates].exec_time)}
        
        ({$_debug_tpls[templates].exec_time|string_format:"%.5f"})
        {if %templates.index% eq 0}(total){/if}
        
    {/if}
    

{sectionelse}
    no templates included
{/section}

 
assigned template variables
 
{sectionname=vars loop=$_debug_keys}{sectionelse}{/section}
     
        
            {ldelim}${$_debug_keys[vars]|escape:'html'}{rdelim}
            {$_debug_vals[vars]|@debug_print_var}
    
        no template variables assigned
    

 
assigned config file variables (outer template scope)
 
{sectionname=config_vars loop=$_debug_config_keys}{sectionelse}{/section}
     
        
            {ldelim}#{$_debug_config_keys[config_vars]|escape:'html'}#{rdelim}
            {$_debug_config_vals[config_vars]|@debug_print_var}
    
        no config vars assigned
    



{else}

{/if}

How it Works

This debug template gives you two options on how to view it: the original method display’s everything in a new pop-up window, the new and awesome method shows the same thing but in the Firebug Console. The template has an if statement/flag that checks whether it should be rendered in HTML or use Firebug. You’ll have to do some digging on how to setup this flag in your configuration, but the flag is in line 4 defined as $_smarty_debug_output.

The default is to use Firebug. A function named Smarty_debug is defined at the bottom at line 143. When you run it in the Firebug console, it will print out the Smarty debug information in the console as collapsible groups. If the browser doesn’t support console, then you probably shouldn’t be using this method, that’s why the HTML version is available.

1	Smarty_debug(); //type this in your Firebug Console

It bothered me a little that Hipska’s method printed out every line in the group once Smarty_debug function is called. Now here’s my tweak: I’ve made it optional to print out as a collapsed group but you WILL need Firebug 1.3+ (if it works on other versions, please let me know). All you need to do is supply a boolean argument.

1	Smarty_debug(true); //prints out a collapsed group

Conclusion

I really love being able to print out the Smarty debug data to the Firebug Console because I won’t have to deal with an additional pop-up every time. I get’s a little annoying and I think it suck’s up more memory. Thank you Hipska and Mike!

Sly, New Selector Engine & How to Use in MooTools

Garrick — Thu, 26 Mar 2009 16:00:44 +0000

You’ve heard of selector engines right? The engine that parses the HTML to match a string argument to return matching HTML elements? How about Sizzle and Peppy (two fast selector engines) that was released? Or how a couple JS frameworks were implementing Sizzle and the MooTools dev team decided not to follow suit?

Now, have you heard of Sly, the new selector engine on the block? No? That’s because Harald Kirschner just released it yesterday, 03/25/09, and I can’t tell you how awesome it is.. or can I?

I’ll start you off with a brief description… and graphs!

Sly is a turbocharged, cross-browser, library-agnostic JavaScript class for querying DOM documents using CSS3 selectors.

And turbocharged it sure is, just check out the stats!

The benefits:

Pure and powerful JavaScript matching algorithm for fast and accurate queries
Extra optimizations for frequently used selectors and latest browser features
Works uniformly in DOM documents, fragments or XML documents
Utility methods for matching and filtering of elements
Standalone selector parser to produce JavaScript Object representations
Customizable pseudo-classes, attribute operators and combinators
Just 3 kB! (minified and gzipped, 8 kB without gzip)
No dependencies on third-party JS libraries, but developers can override internal methods (like getAttribute) for seamless integration.
Code follows the MooTools philosophy, respecting strict standards, throwing no warnings and using meaningful variable names

Use it in MooTools?

Yes, that’s right. You can use it in MooTools right now, though I don’t think it’s necessary since the MooTools selector engine is very good. But just like how David Walsh showed us how to use Sizzle and Peppy in MooTools, you can do the following to use Sly:

Window.implement({
    $Sly: function(selector){
        return new Sly(selector);
    }
});
 
// returns an array of all the anchors in the page
$Sly('a').search();
 
// returns the first anchor on the page
$Sly('a').find();

Now, you may be wondering whether doing this will allow you to use MooTools methods on the elements. Well, the good news is that you can because the MooTools Elements class applies the methods to all elements. Observe:

1 2	// returns the href of the first anchor $Sly('a').find().get('href');

And lastly, Oskar Krawczyk posted how to replace the $$ function itself (thanks Oskar!):

Window.implement({
    $$: function(selector){
        return Sly.search(selector);
    }
});

Great job, Harald, great job indeed. Way to represent!

Solution to Flash and Select Drop-downs Covering HTML Elements

Garrick — Wed, 03 Dec 2008 13:00:15 +0000

I’ve positioned elements absolutely and had to deal with a bug where the element appears below a flash object or select drop-downs, which usually occurs in IE. I’ve seen a few solutions, which work great, and I have one more to add.

Solution 1: iFrame

This solution comes from Joe King’s post.

In case you don’t already know, windowed controls in IE will always cover DHTML layers. That means if you have a DIV that pops up or floats on the page and it intersects with a windowed control (such as the common SELECT box), the windowed control will obscure the DIV, no matter what zIndex you have set for each element.

The solution is to create an iFrame shim under the element that needs to appear above the select drop down.

var element = $('id_of_element');
var iframe_shim = new Element('iframe', {
    'id': 'shim',
    'scrolling': 'no',
    'frameborder': 0,
    'styles': {
        'width': element.getSize().x, //Plug in the width of absolutely positioned object here
        'height': element.getSize().y;, //Plug in the height of absolutely positioned object here
        'filter': 'progid:DXImageTransform.Microsoft.Alpha(style=0,opacity=0)' // fixes transparency
    }
}).inject(element,'after'); //this automatically injects the shim after the element.

Keep in mind you’ll probably need to modify this to work with your needs. E.g. For drop down navigation, you would create the shim and use Javascript to make adjustments to the position and dimensions of the shim to reflect that dropped down menu in the navigation.

Solution 2: Flash Param: wmode=transparent

This solution was found on CSS Play by Stu and Fran Nicholls.

So you have a flash object and you require HTML elements to appear above it. You set the HTML elements positioning to absolute and try z-index, which probably didn’t work in IE. You only need to set the flash object’s wmode parameter to transparent to fix this. Use the to set the name/value, and set the wmode attribute on the tag like so:

1
2

Solution 3: Markup Hierarchy

Let’s say you have a flash object that you have no control over, such as a YouTube video. The flash object comes in with wmode=”window” or something. What do you do? Consider markup hierarchy. In IE, the next HTML element is considered at a higher layer than the element before it.

1 2	Box 1 Box 2

Box 1 will appear above Box 2. So using the drop down navigation as an example again (from solution 1) I would use Javascript to relocate the navigation’s html markup below the flash object and adjust the positioning of the nav to make it look like it never moved via CSS.

Run Javascript Functions Without using ‘domready’ Event

Garrick — Sun, 09 Nov 2008 01:35:27 +0000

I don’t really like using the ‘domready’ event. The idea of adding another event to the window object just bugs me. So here’s the alternative. In short, an array is created, functions you want to run are added to the array, and when the page reaches the bottom the functions in the array are run.

The Code

I create my namespaced object literal which includes an array to keep all the functions I want to run. This would be at the top in the .

if(!GTC_CORE){
    var GTC_CORE = {'init': []};
}
 
GTC_CORE.init; //returns an empty array

At the bottom of the page, right before the tag, I have the code to run all the functions that are in the GTC_CORE.init array. Here I will be using MooTools Array.each() method.

if(GTC_CORE.init.length){
    GTC_CORE.init.each(function(func){
        func();
    });
}

Adding Functions to the Array

If you have ‘domready’ blocks in the content between the tags, it’s a simple change. I’ll give you the before and after.

//Before
window.addEvent('domready', function(){
    //Load this stuff here
});
 
//After
GTC_CORE.init.push(function(){
    //Load this stuff here
});

Simple as pie and one less event to add. Keep in mind that ‘domready’ is used to make sure that the DOM elements were all loaded. If you need something to happen on ‘load’, then that’s a different story. The ‘load’ event makes sure that even the images are done loading, where the ‘domready’ event does not.

Don’t Pollute the Global Space; Namespace It!

Garrick — Sat, 08 Nov 2008 01:07:08 +0000

I like to namespace my code with object literals to contain all my functions and classes. It keeps things organized, decreases global space pollution from additional functions, and prevents conflicts with third-party scripts. It’s very easy to extend too.

Create the Namespaced Object

I usually start out by checking whether the namespaced object literal is already existing, and if it’s not, then create one. You can use the name of the website, or your initials, whatever works. I’m going to use my initials and “CORE”.

1
2
3

if(!GTC_CORE){
    var GTC_CORE = {};
}

Extend your Namespace

Like I said, I like to use dot notation. It’s just my preference.

GTC_CORE.printHello = function(){
    alert('Hello!');
}
 
GTC_CORE.printWelcome = function(){
    alert('Welcome!');
}

Namespace in Action

So here we have a GTC_CORE namespaced object. Now let’s say we want to run the printHello function. You just run it like how you do any other function you’ve written.

1 2	GTC_CORE.printHello(); // Alert appears printing 'Hello!' GTC_CORE.printWelcome(); // Alert appears printing 'Welcome!'

Alternative to Dot Notation: Start with the Object Literal

There are other ways to create a namespace. Here we’re just plugging in the functions into the object literal GTC_CORE. Notice that every addition requires a comma, except the last one. I’ll also throw in a couple examples for variables and nesting object literals inside.

var GTC_CORE = {
    // printHello function
    'printHello': function(){
        alert('Hello!');
    },
 
    //printWelcome function
    'printWelcome': function(){
        alert('Welcome!');
    },
 
    //the value of 'name' is Garrick, a string
    'name': 'Garrick',
 
    //the value of 'num' is 12, an int
    'num': 12,
 
    //nested object literal
    'nested': {
        'val1': 1,
        'val2': 2
    }
}
 
GTC_CORE.printHello(); //Alerts with "Hello!"
GTC_CORE.printWelcome(); //Alerts with "Welcome!"
GTC_CORE.name; //returns 'Garrick'
GTC_CORE.num; //returns 10
GTC_CORE.nested; //returns object literal

Get Around Form submit() Mapping

Garrick — Tue, 04 Nov 2008 06:32:27 +0000

If you’ve had to use javascript to submit a form, you may have used the forms submit() method. You may also experienced difficulty, such as a “submit is not a function” error. It has to deal with mapping and I’ve got a very simple solution.

The Setup:

Just so you know, this is done with MooTools 1.2, but if you know javascript, you can build it from scratch.


    
        Test
        Grab the response.

<script type="text/javascript">
var form = $('response_form');
form.getElement('input[type=submit]').addEvent('click', function(e){
    e.stop();
    form.submit();
});
script>

The Test:

Copy the code into a test html file. Open Firebug (you DO have Firebug and FireFox, don’t you?) and display the console. Click on the submit button and there should be an error.

The Solution:

Very simple now. Change the name to anything besides submit and you’ve fixed the mapping issue.

This one took me a while to find, but I was glad when I did. I hope this is helpful.

What I Learned About Multi-threading in JavaScript

Garrick — Sat, 01 Nov 2008 04:01:22 +0000

There’s no such thing. Correct me if I’m wrong, but multi-threading in javascript does not exist. But we can simulate it, as is discussed by James Edwards. How does it work?

It all hinges on the use of asynchronous timers. When we run repetitive code inside an asynchronous timer, we’re giving the browser’s script interpreter time to process each iteration.

This is a solution for those times we have our scripts set up to do some major processing with loops, which causes the browser to hang. In Firefox you get an “unresponsive script” warning during those times.

Effectively, a piece of code inside a for iterator is asking the interpreter to do everything straight away: “run this code n times as fast as possible.” However the same code inside an asynchronous timer is breaking the code up into small, discreet chunks; that is, “run this code once as fast possible,”—then wait—then “run this code once as fast as possible”, and so on, n times.

The trick is that the code inside each iteration is small and simple enough for the interpreter to process it completely within the speed of the timer, be it 100 or 5,000 milliseconds. If that requirement is met, then it doesn’t matter how intense the overall code is, because we’re not asking for it to be run all at once.

The Code

function checksomething(){
    var okay = false;  
    var i = 0, limit = 100, busy = false;
    var processor = setInterval(function(){
        if(!busy){
            busy = true;
 
            if(condition){
                okay = true;
            }
 
            if(++i == limit){
                clearInterval(processor);
            }
 
            busy = false;
        }
 
    }, 100);
}

Notice that in line 4 we’re setting an interval to run a function every 100ms. Once the iteration has met the limit, it clears the interval. So basically, we have something running in the background every 100ms. This solves the problem of causing the browser to spit out the “unresponsive script” warning. But there’s another problem. If you want the function to return something, it will always return false because:

…the inner function is asynchronous. The outer function will return before the first iteration of the inner function has even happened!

This got me thinking about how I’ve used callback functions when doing ajax requests. Basically, you pass in a function as an argument and have it run inside the function.

var test_func = function(){
    alert('this is test func.');
}
 
var test_func2 = function(callBack){
    alert('this is test func 2.');
    callBack();
}
 
test_func2(test_func);
/* Result is an alert appears stating "this is test func 2" and right after another alert appears stating "this is test func". */

Upon reading further, James also had the same idea.

function checksomething(oncomplete){
    var okay = false;
 
    var i = 0, limit = 100, busy = false;
    var processor = setInterval(function(){
        if(!busy){
            busy = true;
 
            if(condition){
                okay = true;
            }
 
            if(++i == limit){
                clearInterval(processor);
 
                if(typeof oncomplete == 'function'){
                    oncomplete(okay);
                }
            }
            busy = false;
        }
    }, 100);
}

You can also use setTimeout()/clearTimeout() instead of setInterval()/clearInterval().

In MooTools 1.2.1

MooTools has some methods to the timing stuff too. The function periodical() method uses setInterval() and the function delay() method uses setTimeout(). Both can be cleared using $clear() by passing in the timer.

var delay_run = run_func.delay(1000); //runs the function in one second.
var periodical_run = run_func.periodical(1000);//runs the function every one second.
 
//Clears the timers
$clear(delay_run);
$clear(periodical_run);

Here’s one of James’ functions but with the periodical() method:

var count_func = function(callBack){
    var i = 0, limit = 20, busy = false;
    var processor = (function(){
        if(!busy){
            busy = true;
            if(++i == limit){
                $clear(processor);
                if($type(callBack) == 'function'){
                    callBack();
                }
            }
            busy = false;
        }
    }).periodical(100);
}

I know it looks pretty much the same. But it’s just SLIGHTLY cleaner.. yeah? Well the point is that now you know about simulating multi-threading in javascript!

Thank you James for introducing me and everyone else to this technique. This was an awesome lesson!

P.S. Word on the street (or a user comment on James’ article) is that:

Per the difference between setTimeout and setInterval, as I understand it, they both generate events, which get put on a queue. Since a webpage basically runs in a single thread, only one event can be handled at a time, so the events on the queue just run in order, one after another- including the timers. Thus, the timer never executes EXACTLY in the interval you specify. The timer only generates an event exactly when you specify, and the event function itself only gets executed whenever the browser’s single thread gets up to it in the queue. One additional consequence is that if a setInterval event happens, and there’s already a setInterval event on the queue that hasn’t been executed yet, the new event doesn’t get added to the queue. So setInterval events get dropped. The smaller you set your interval, and the more complex your function, the more likely they are to get dropped.

this doesn’t happen with setTimeout however. Since the new setTimeout events don’t get added until the last setTimeout function has finished, you never have more than one timer event on the queue at a time.

I suggest figuring out a way to use setTimeout to make sure that a timer event isn’t dropped.

Form property set/get error with MooTools in Internet Explorer

Garrick — Thu, 16 Oct 2008 09:13:51 +0000

When I was working on TV.com‘s redesign, I found an error when setting or getting a form element’s properties in IE. The other browsers was able to set or get the property just fine. So I’m going to share my solution with you today. I’ll go over the methods MooTools has first so you know what I was doing.

MooTools Set or Get

MooTools has two sets of methods when setting or getting an elements properties.

You can use the set() or get() method like so:

//Element Method: set
$('anchor_id').set('href', 'http://www.testurl.com'); // sets the element's href
 
//Element Method: get
$('anchor_id').get('href'); // returns the element's href as a string

Or you can use setProperty() or getProperty() methods:

//Element Method: setProperty
$('anchor_id').setProperty('href', 'http://www.testurl.com'); // sets the element's href
 
//Element Method: getProperty
$('anchor_id').getProperty('href'); // returns the element's href as a string

Note: There’s also methods to set/get more than one property and remove property(s) using:

Error Up Ahead!

The problem I came across was when I wanted to set or get a form elements property in IE. If the form element contained an element with a name property that is the same as the form elements property name then an error would occur. Here’s the code example:

HTML:

Javascript:

var form = $('test_form');
// grab the element
 
var get_action = form.get('action');
// IE returns null, others return the url as a string
 
var getProperty_action = form.getProperty('action');
// IE returns null, others return the url as a string

Eureka: The Solution!

The only way I could find around this was to use Javascripts native method when dealing with DOM elements. Take a look at this code:

var form = $('test_form');
// grab the element
 
var get_action = form.getAttributeNode('action').nodeValue;
// IE, and the other browsers, returns the url as a string

Now you just need to remember not to name your child nodes the same name as the name of the parent form elements property so you can continue to use MooTools method, or use the native method.

Inspired by Aaron Newton’s “Programming to the Pattern”

Garrick — Tue, 14 Oct 2008 06:33:56 +0000

Aaron Newton is a contrbutor to MooTools and the care-taker of Clientside, CNET.com’s developer blog. He recently wrote about being inspired to write code differently and a more indepth post about his thoughts on (take a deep breath if you’re verbally reading this) “jQuery, MooTools, the Ajax Experience, Programming to the Pattern, and What Really Makes One Framework Different From Another“. He has inspired me to be more aware of how I write my code.

Programming to the Pattern

Aaron’s says:

When I write my code, I can choose to be an architect, or a construction worker. I can design, or I can implement. In reality, I must do both, but I can choose which one I want to do more and, in many ways, it’s possible for me to do almost entirely one or the other – though not 100%.

What the hell am I talking about? Let me put it to you this way: if you write 20 lines of code to describe a user interaction on a page to make it snazzy or easier to use, is it worth writing another 5 or 10 lines to make that code reusable? If you program the experience directly, you’ll always write it again and again. But if you program the pattern, you’ll write less and less.

This part really got me thinking because I know I don’t want to keep re-writing code, but that’s just what I’ve been doing. I’ve tried writting my classes to be reuseable, and so have my co-workers, though the only real way to reuse it is to not only copy of the class, but use the same HTML markup as well, which I don’t really want to do because other people may have different markup.

His code example is a really good one:

var PopupForm = new Class({
	Implements: [Events, Options],
	options: {
		requestOptions: {/*the user can fill in additional ajax options*/},
		onComplete: $empty //do nothing on complete by default
	},
	initialize: function(link, form, popup, options) {
		this.form = $(form);
		this.link = $(link);
		this.popup = $(popup);
		this.setOptions(options);
		this.makeRequest();
		this.attach();
	},
	makeRequest: function(){
		this.request = this.form.retrieve('send', this.options.requestOptions);
		this.request.addEvent('complete', function(response){
			popup.set('html', response);
			this.fireEvent('complete');
		}.bind(this));
	},
	attach: function(){
		this.link.addEvent('click', this.show.bind(this));
		this.form.addEvent('submit', function(e){
			e.stop();
			this.request.send();
		}.bind(this));
	},
	show: function(){
		this.popup.show();
	},
	hide: function() {
		this.popup.hide();
	}
});

He goes on to show that you can also extend this class by changing the show and hide functions to add some animation.

I also really like the benefits he stated:

My code is now far more legible. I have small methods that just do one thing and I know what it’s doing and why. My classes are named things that describe what they do, and the classes themselves are small things that just do one thing. If I need a class that does two things, I write two classes and a small controller class that calls them.

My code is reusable – if the pattern ever comes up again, I don’t have to write it again. I’ve amazed myself in how often this has happened. Stuff I never, ever thought I’d reuse ends up coming back to me in a week and there I am using it again.

The points where my application – the web page I’m working on at the moment – touches my generic code are very small. I don’t write much code about the pages themselves – all I do is instantiate classes for a given page element. This small footprint means that there’s less code that’s only good for that page.

When it’s time to refactor – perhaps there’s a new version of the framework I’m using, or a new browser bug is found, or a new browser hits the market (oh, hi chrome), or I find a bug in my own code (which is the most frequent of all these reasons), I have to go fix it. If I’m writing all my code for each page I have to go refactor it everywhere. If, on the other hand, my pages just instantiate my classes, I only have to refactor my classes. Since I control the interface to my classes, I can completely rewrite the class without having to touch the code that instantiates them.

Finally, I end up changing the way I think about the user experience I develop. I’m much more likely to develop an experience and reuse it than create a new one from scratch. This creates an experience consistency that, to me, means a better user experience.