To compliment the PHPQuickFix site/twitter account, I’ve started up a Javascript-centric feed of hand-picked items I find in my reading that look useful/interesting/are more than just fluff – JsQuickFix (and @jsquickfix on Twitter).

This uses the same setup I have for the PHPQuickFix feed:

• using GimmeBar as a data source
• a simple PHP script to generate an RSS feed of the latest assets
• Twitterfeed to pull the latest from this feed and post to Twitter

I use the Chrome extension that adds a GimmeBar icon to my toolbar and makes adding new links to these services a few simple clicks away.

To accomplish this, though, I had to shift over to using Collections instead of just pointing it at my main GimmeBar Public feed. Here’s the two collections that will grow in the future:

• JsQuickFix
• PHPQuickFix

Enjoy!

[javascript]
Ext.create(‘Ext.toolbar.Toolbar’, {
floating: false,
id: ‘menuToolbar’,
cls: ‘appMenu’,
height: 30,
items: [], // dynamically built below
listeners: {
beforerender: function() {
var navStore = Ext.create(‘Ext.data.Store’, {
fields: [‘text’],
proxy: {
type: ‘ajax’,
url: ‘/path/to/navigation-output’,
reader: {
type: ‘json’,
root: ‘navigation’
}
},
autoLoad: true,
listeners: {
load: function(store,records,success,operation,opts) {

var toolbar = Ext.getCmp(‘menuToolbar’);

// First the top level items
store.each(function(record) {

var menu = Ext.create(‘Ext.menu.Menu’);
Ext.each(record.raw.menu, function(item){
menu.add({
text: item.text
})
})

toolbar.add({
xtype: ‘button’,
text: record.data.text,
menu: menu
});
});
}
}
});
}
}
});
[/javascript]

Then the PHP to make the output is pretty easy (slightly simplified here):

[php]
<?php
echo json_encode(
‘navigation’ => array(
‘text’ => ‘Option #1’,
‘menu’ => array(
array(‘text’ => ‘Foo’),
array(‘text’ => ‘Bar’),
array(‘text’ => ‘Baz’)
)
)
);
?>
[/php]

Now – a little explaination of what we’re doing here:

1. In Ext, we create a generic Toolbar object – this is what’s going to contain the “buttons” that act as the top level menu.
2. There’s a few config options (like an ID, height and a custom class to apply) but the key is in the “listeners” section. This is where Ext looks to for events on the objects. In our case, we’re telling it to, on the “beforerender” event, call this given inline method. This method then makes our store.
3. For those not familiar with the ideas of “stores”, think of them as Javascript-based database tables (kinda). They pull in data from some source or can be manually populated in memory to prevent you from having to go back and fetch the data every time you need it. in our case, we just make a basic one (Ext.data.Store) that is set up with a proxy to pull from the JSON source (our /path/to/navigation-output). With the “autoLoad” property set to “true” it automatically pulls in the JSON as soon as it’s created.
4. You’ll see that we’ve, once again, tapped into the “listeners”, this time for the store. Our “load” listener fires when the store data is completely loaded. In here is where we’re going to add our elements into the Toolbar.
5. As one of the options, we get the current store back and we use it to loop through and get each of the records. Each of these top level records is going to be one of our Toolbar buttons, each with its own menu. You can see as we loop through them, we create an “Ext.menu.Menu” object adding the “text” value to it. This menu is then appended to the button via the “menu” property on the button. The “add” is called again on the button config and it’s dropped into the Toolbar.

The fun thing about this is that it makes a reusable component that you can use across products/sites without having to hard-code the navigation options into the actual code. There’s probably a simpler way to do this, but this one seemed to make the most sense to me.

I’m a big fan of unit testing and promote it whenever I can – not only does it help create a code base that a better quality, but it also lets you keep things consistent. No more of the “cross your fingers” kind of coding. A good, well-written set of unit tests can save you a whole world of hassle in the long run. Taking it one step further, you get to TDD (test-driven development) where you write your tests before you even write your code. You start with the usual “W”s – why, where, when, how (yes, I know that last one’s an “H”s) and develop the test for those rather than looking at a current chunk of code and testing what it already does. There’s some people that swear by it, one of them being the author of this book.

He starts with an introduction to TDD and a general how-it-works with javascript quickly followed by an introduction to his tool of choice – JsTestDriver. All of the test examples in the following chapters are run with this tool. Thankfully it’s simple to set up and even easier to write tests for. He shows some introductory tests to help you get familiar with things before diving into the next section – testing javascript itself.

I have to admit, this section left me at a loss for words. I thought I knew a good bit about how javascript works, both out in front and behind the scenes. I was surprised, however, just how much of the functionality he tested I had no idea worked that way. It’s pretty in-depth, so if you’re a beginning javascript dev, you might go read some more tutorials before diving right in.

I’m just now getting to the “Unobtrusive Javascript” part of the book (Part 2, Chapter 9) so I still have a ways to go, but each page is enlightening, especially for some one like myself that’s has a primary focus on backend work and unit testing. I’d definitely recommend this book to anyone looking to get into testing their frontends – it’s a great resource and can probably teach you a thing or two.

I’ll try to put up another post when I get closer to the end – it’s hard to find time to sit and read these days, but just little nibbles at a time work just fine.