Long story short, this particular client (a restaurant) asked me to add some new content to their menu. Rather than expecting the user to scroll down a lengthy list of mouthwatering lunch options, I suggested that we add tabs to the menu in order to logically separate the menu items.

Since I already had jQuery 1.3 running the slide-show on this website I simply decided to build the menu tabs in jQuery to maintain consistency. But I was suddenly struck by an idea: why not compare how ExtCore and jQuery UI create tabs from HTML markup!

ExtCore

ExtCore can be downloaded from the ExtJS website, and an online demo of the simple tabs can be seen here.

The first step to building tabs from HTML markup using ExtCore is to reference ext-core.js in your page header. You also need to include the tabs.css file and the “images” folder containing the necessary 5 background images. (These can be found under “/examples/tabs/” of your ExtCore download ZIP.)

Note: I’m using ExtCore 3.0, although I believe 3.1 is available for download.

Next, we need to add the appropriate HTML markup for our tabs. Here’s a quick example.

As you can see from the picture above, ExtCore takes a wrapping DIV element (class “tab_container”) and converts a nested unordered list into the tabs. Subsequent child DIV elements contain the markup for each tab’s content. (The source code in this example is taken directly from the ExtCore tab example.)

The only thing to notice is that each DIV element has a CSS class assigned to it – these classes are essential to proper tab theming. The DOM ID properties are used to click back-and-forth between tabs.

Lastly, you need to include a JavaScript snippet which converts your HTML markup into a fancy tabbed widget:

jQuery UI

jQuery UI has a tab widget which is dependant on the larger jQuery library. An online demo of their tab widget can be seen here.

The first step to using tabbed content with jQuery is to reference:

• jquery-1.3.2.min.js
• jquery-ui-1.7.2.min.js

Your file versions may differ (I think jQuery 1.4 was just released), but these are the versions I’m using. I’m also using the “smoothness” theme – for some reason jQuery UI would not allow me to download the package without specifying a theme. (That may affect my analysis for speed in the next section.)

You will also need to include the CSS file and images folder included with your download of jQuery UI. In my case, it’s jquery-ui-1.7.2.css and an “images” folder containing 13 background images.

Next, write your HTML markup:

Compared to ExtCore, jQuery UI expects less HTML markup as we lose several layers of nested DIV elements. The most obvious difference between jQuery UI and ExtCore is probably that jQuery UI doesn’t need the extra CSS classes applied to the DIV elements.

Next, we add our JavaScript snippet:

Again, jQuery UI expects less code to generate the tabbed widget.

A Deeper Look

Let’s take a look at the file sizes for each library. This is about as un-scientific a study as it can get; I’m using Firebug’s “Net” tab to grab file size and download speed numbers. These numbers will probably be different for you because of any number of factors… but you get the idea.

As I already mentioned, ExtCore requires 1 JavaScript file, 1 CSS file and only 5 background images:

• ext-core.js (78.9 KB, 156ms)
• Ext.tabs.css (1.3 KB, 147ms)
• 5 png files (2.8-2.9 KB each, average 107ms)

Combing the file sizes and their download times (on my home network), you get a total of roughly 94.7 KB taking 838ms.

jQuery UI requires 2 JavaScript files, 1 CSS file and 13 background images (again, with the “smoothness” theme):

• jquery-1.3.2.min.js (55.9 KB, 116ms)
• jquery-ui-1.7.2.min.js (188.1 KB, 221ms)
• 13 png files (22.3 KB total*)

*Something interesting I noticed about the jQuery UI tabs is that my page only seemed to load 5 of the 13 background images, totaling something like 605 bytes and a total of 684ms. Perhaps someone more familiar with jQuery can explain that to me… I didn’t dig deep enough to figure out what was going on, but I’ll base my total on what Firebug says. I’m guessing that I’m not using all of the CSS background images for this theme.

Overall, that brings jQuery UI tabs to a total of roughly 245 KB taking 1021ms.

What Does That Even Mean?

According to my inaccurate, quasi-scientific study it appears that ExtCore requires slightly more code than jQuery UI. On the other hand, ExtCore also appears to be downloaded by my browser more quickly than jQuery UI. In reality, those numbers probably offset each other as the extra markup required by ExtCore increases the HTML file size. The fact that I’m using a theme on jQuery UI probably also has a slight impact on performance.

Which do I prefer?

In essence, both libraries create tabbed widgets from the same basic HTML markup – though the differences are significant enough that they’re not cross-compatible.

Judging both frameworks as they stand in my examples, I will say that I like the conciseness (is that a word?) of jQuery with regards to both HTML markup and JavaScript code. But I also like that ExtCore requires fewer files. As someone who uses the larger ExtJS framework a great deal, I’ll say that I am very likely to choose ExtCore over jQuery UI most days of the week.

Are there any ExtCore or jQuery UI users out there? What do you think?

I’ve been talking about the need for a solid JavaScript unit testing platform for a while, specifically in relation to ExtJS. I gave a presentation on the subject a few months ago and have received some great feedback from the ExtJS community. I encourage you to take a look – I find it extremely helpful in my own day-to-day development.

See the interactive demo here.

Although I’ve been involved with several projects in the past, this is the first open source project that I have started on my own – and I had to stumble my way through the SVN setup. As ExtJS 3.x was released under the GPL v3 license, the ExtJS licensing team advised me to use the same license for this project.

If anyone is interested in contributing (or just wants to submit bug/feature requests) please don’t hesitate to contact me.

I’ve been working on an application for some time that necessitates changes to my grid’s toolbar depending upon several factors. The challenge that I’ve run into is that the default Ext.Toolbar() object is not very helpful when you try to show/hide options which are not specifically grouped.

For example, let’s say that you have a layout like the one pictured below. This particular layout allows the user to manage a list of physical locations and group them into categories.

As you can see, the grid has several top-level UI elements: a drop-down menu, a combo-box and several generic buttons. Our drop-down menu also has multiple options for the user to select (add/remove, etc).

This application requires that certain options are only visible when the grid is in its default (or ‘root’) view. Other options become visible (or hidden) when the grid is filtered by clicking on a category in the tree or by selecting a previously saved search algorithm. In other words, the toolbar’s functionality depends on some kind of state.

Now as far as I know, there isn’t a plugin or user extension available which meets the requirements my application needs. Therefore I created my own!

Override Toolbar Buttons/Actions

The first thing I needed to do was mark which toolbar options need to be hidden in specified states. I did this via a simple override statement on Ext.Component() and Ext.Action(). This was necessary because ExtJS toolbars can contain any Component() sub-class AND Ext.Action() instances which do not inherit from Component(). Thus I needed to cover both cases.

/**
 * Add markAsHidden member to all Components.
 * Used for marking toolbar items/buttons as hidden
 */
Ext.override(Ext.Component, {
    markAsHidden: []
});
Ext.override(Ext.Action, {
    markAsHidden: []
});

The new “markAsHidden” member  is an array (defaults to an empty array) which can be given any number of ’states’ in which the button or action must be hidden from the user.

You can now add these states via the button/action config:

var myButton = new Ext.Action({
    text: 'My Button',
    markAsHidden: [ 'someState', 'anotherState' ],
    handler: function() { ... }
});

Extend Ext.Toolbar()

My.Toolbar() is a basic extension of the Ext.Toolbar() object, with only two things which require explanation.

/**
 * @class My.Toolbar
 * @extends Ext.Toolbar
 * @constructor
 * @param {object} configObj
 * @cfg {array} items
 */
My.Toolbar = function(configObj) {
    var thisObject = this;

    /**
     * @method
     * @description Method to update the toolbar, showing/hiding specified
     *     buttons based on the passed display type.
     *     Common values are: 'root', 'child', 'query'
     * @param {string} displayType
     */
    this.updateDisplay = function(displayType) {
        function checkForHiddenFlag(toolbarItem) {
            if (toolbarItem.markAsHidden.indexOf(displayType) == -1) {
                toolbarItem.show();
            }
            else {
                toolbarItem.hide();
            }

            //cascade into the menu actions
            if (toolbarItem.isXType('button')) {
                if (toolbarItem.menu) {
                    toolbarItem.menu.items.each(checkForHiddenFlag);
                }
            }
        }

        thisObject.items.each(checkForHiddenFlag);
    };

    Ext.apply(this, {
        items: configObj.items
    });

    My.Toolbar.superclass.constructor.apply(this, arguments);

    this.mon(
        thisObject,
        'render',
        function(thisComponent) {
            thisComponent.updateDisplay('root');
        }
    );
};
Ext.extend(My.Toolbar, Ext.Toolbar, {});

First, I added an updateDisplay() method which (when called with a string parameter) will hide any toolbar options marked to-be-hidden in the specified state. It even goes into sub-menus to hide menu options!

Second, I run updateDisplay(‘root’) when the toolbar renders to put the grid into a default state.

So… now what?

The idea is that we can change the state of the toolbar whenever we need to – like on UI events such as tree-node clicks or a combo-box selection.

myTree.on(
    'click',
    function(theNode, theEvent) {
        myGrid.getTopToolbar().updateDisplay('someState');
    }
);

This extension is still a bit of a work in progress, but hopefully it helps a few of you ExtJS developers out there!

Disclaimer: I am not getting paid for this review, but I did get the book for free. I don’t work for ExtJS or Packt Publishing.

Who this Book is for

ExtJS 3.0 Cookbook is definitely geared towards JavaScript developers who have some basic understanding of and experience with ExtJS 3.0. If you’re brand-new to ExtJS, you may want to wait a few weeks until you’ve spent some time playing with the various components and layouts that ExtJS offers.

As an experienced ExtJS developer, I can say with absolute certainty that I learned some new tricks while reading this book.

Let’s Start with the Bad

I want to start by pointing out the things I didn’t like about this ExtJS 3.0 Cookbook. Why? Because you should read this book, and I want you to walk away from this post remembering the things I liked!

Overall, a general complaint I have about the examples is that many of them are similar to those given on the ExtJS website. If I were writing my own book (which I haven’t done…) I would try to come up with more unique examples. Jorge did spend some time doing that – but not enough time for my liking.

Chapter 1 (DOM and Data Types, the ExtJS Way) seemed a bit all-over-the-place. While the examples and explanations were well written, topics like building custom ExtJS extensions are complicated. For developers new to ExtJS, a more in-depth focus will absolutely be necessary. Topics like sniffing the user’s browser or OS aren’t advanced enough to interest seasoned ExtJS developers. Overall, I thought Chapter 1 was a bit of a waste.

Chapter 2 (Laying Out a Rich User Interface) doesn’t mention HBOX and VBOX layouts – two of the most useful layout containers. These layouts were new features in ExtJS 3.0, and I’m disappointed that Jorge didn’t give any explanation of them.

Chapter 6 mentions a drag/drop implementation between two grids (basically the example seen here) – which is a great introduction – but only spends 4 paragraphs explaining the example. Drag-and-drop is one of the most useful (and often confusing) concepts in ExtJS, and I’m disappointed that this example wasn’t expanded. In fact, Jorge probably should have devoted an entire chapter to this example, maybe even adding some extra functionality.

I also thought it was odd that Chapter 7 (Keeping Tabs on your Trees) covered TabPanels and Trees at the same time. Although I often use the two together when building my user interfaces, I think the topics could have been covered separately and each given more attention. Specifically, I don’t have much experience with the ColumnTree extension or drag/drop between TreePanels… I don’t know why they’re in the same chapter as the TabPanel.

Lastly, I don’t know why Jorge added the Ext.Slider() to Chapter 9 (Well-charted Territory). The Slider() isn’t a chart, and he doesn’t add it into an example using a chart. It’s just out-of-place.

Things I Really Liked

Throughout the book, Jorge Ramon shows the reader examples using three distinct headers:

1. Name of the concept
2. How to do it…
3. How it works…

Ramon’s approach to explaining the examples is virtually flawless, and the box-style headers make it easy to follow. I haven’t seen too many coding books use this technique, so kudos to whoever thought of it!

Chapter 2 (Laying Out a Rich User Interface) has a lot of good stuff. I was particularly impressed when I saw the Portal drag/drop example, although I didn’t really dig deep enough to see if it’s the same example shown on the ExtJS website. In either case, Jorge did a great job explaining how it all works!

Chapter 3 (Load, Validate, and Submit Forms) was more useful to me than I thought it would be. Forms are the basis of web-based applications, and any developer using ExtJS has (more than likely) had to create Ext.form.FormPanel() objects at some point. Awesome tips included: changing the location of validation errors and auto-validation of URLs/email addresses.

Chapter 4 (Fun with Combo Boxes and Date Fields) has a lot of great examples for customizing these two widgets. The best samples in this chapter involve XTemplates and data-paging on the ComboBox, and disabling days/dates in the date picker. I actually didn’t know you could disable days/dates on the date picker widget… I learned something!

Chapter 5 (Using Grid Panels to Display and Edit Tabular Data) didn’t really teach me anything new, but I will say that I was impressed by the number of examples Jorge uses to demonstrate the power of the ExtJS grids. This chapter covers everything from using remote data sets (in both XML and JSON) to inline editing, grouping and expandable rows. If you’re not an expert on ExtJS grids before you read this chapter, you’ll know everything you need to know when you’re finished!

Chapter 6 (More Applications of Grid and List Views) is another great compilation of examples which build on the ExtJS grid. ExtJS GridViews are (in my opinion) one of the best features of the entire framework because they allow the developer to customize the way the UI displays the data. Jorge also covers the RowEditor plugin (new in ExtJS 3.0) and dives into creating grid cell tooltips.

Chapter 8 (Making Progress with Menus and Toolbars) demonstrates a bunch of ways to make your application interactive. While most of the examples won’t blow your mind, I found that they do spark ideas to accomplish any number of things. I particularly liked the customization of the progress bar!

Finally, Chapter 10 (Patterns in ExtJS) contains solid direction for developers looking to build rich internet applications with ExtJS. In all honesty, this chapter could probably be expanded into a separate book… but it serves as a nice conclusion for the previous nine chapters. Jorge builds on many of the examples he mentioned in earlier chapters and gives some final advice for developers to move forward with their own applications.

The Best Chapter

If I had to pick a single reason to buy ExtJS 3.0 Cookbook, it would definitely be Chapter 9 (Well-Charted Territory).

Why?

For starters, the ExtJS website samples don’t do a great job explaining how to use many of the available charts. The online documentation also lacks direction. Jorge is the first person I’ve seen who thoroughly explains how to use each type of chart, and his examples are both unique and helpful. Kudos!

Final Thoughts

I really liked this book!

I’ve read a lot of programming textbooks, and none are nearly as helpful or interesting as ExtJS 3.0 Cookbook. It is a quick read for containing 356 pages, and Jorge Ramon does a fantastic job offering tips and tricks for ExtJS developers.

Regardless of your experience level, the ExtJS 3.0 Cookbook will absolutely teach you something new!

I’m very excited to read this book, and I’ll be posting my review within a few weeks. The book is intended for: “Ext JS users who want a book of useful techniques, with explanations, that they can refer to and adapt to their purposes. Developers who are already familiar with Ext JS will find practical guidance and numerous examples covering most of the library’s features and components that can be used as a solid foundation to build upon when creating rich internet applications.”

According to the Packt Publishing site, the book covers the following topics:

• Mastering ExtJS widgets
• Creating custom components
• Building forms with custom validation
• Exploring Layouts
• Drag-and-Drop
• Use patterns and state management

My copy of the book is in the mail and should be arriving shortly, but you can order a copy for yourself by clicking on the book cover above. Happy reading!

With the release of ExtJS 3.0 earlier this year, developers can now create and use charts of various kinds. The ExtJS chart classes (Ext.chart.*) are basically extensions of the YUI charts – which has made my life difficult because neither YUI nor ExtJS does a fantastic job documenting how to use them. To be fair ExtJS has done a great job updating their 3.0 docs with the help of the community (charts included), but the chart documentation is still far from ideal.

My biggest beef with the Ext.chart.* docs has to do with the ability to change the default colors. While some references on how to do this can be found on the ExtJS forums and by searching Google, no solid examples exist as far as I can tell in either the ExtJS or YUI documentation. I only stumbled across the solution to this problem while searching Google.

The key to changing a chart’s colors lies in the “series” attribute of a given chart. This config option takes an array of Object literals defining each series on the chart – things like “displayName” and (most importantly) “style”. The “style” attribute has a “colors” property which takes an array of color values.

For example, let’s create a Pie Chart. A Pie Chart will only have one series, and doesn’t need much defined for the series’ attributes (it really only needs the “style” attribute to define the colors we’re going to use).

As you can see, the series style defines colors for the Pie Chart in the order they’re going to be used. Since our data store contains three records, “Pending” will get a blue color, “Passed” will get a green color, and “Failed” will get a red color.

See an example implemented within my ExtJS Unit Testing demo.

In 3.0, the CSS data is divided into two logical groups: structural and visual. This makes creating custom themes much easier than it had been in 2.x, as the developer (in most cases) isn’t interested in changing structural CSS definitions. By isolating the visual CSS, developers can play with colors, fonts, and other presentational elements without worrying about breaking their application.

The only problem with the improvement is that it left many of the cool 2.x templates behind. New CSS rules prevent some things from rendering correctly – though which “things” depends entirely on which template you might have been using.

Searching the ExtJS message boards, you’ll notice a handful of 3.0 templates – but not an overwhelming number. To save you some time, I compiled a small list:

• Blueen
• Gray
• TargetProcess
• Slate

Of course, the standard “blue” theme comes with 3.0 as a default.

I had been using the Slickness Theme for my application, and I was dreading the thought of having to give it up as I migrated to 3.0. Much to my surprise, the Slickness theme (built for 2.x) works almost perfectly in 3.0! I had to make a few minor CSS adjustments (available here), but here’s what my customized Slickness theme looks like:

If you’d like to try out my customized Slickness theme, simply include the “xtheme-slickness.css” file (as you would for any theme), but also include my “xtheme-symphony.css” file AFTER the Slickness CSS file. This way, my CSS styles override the necessary parts of the Slickness theme.

I also attempted to create my own custom theme for ExtJS 3.0 – though I’ll admit it didn’t look nearly as good as the Slickness theme. I basically fake my way through Photoshop, so editing the CSS sprites was a pain in the ass for me. All things considered though, I had a fully customized theme in under 4 hours of work. If you’ve never worked with CSS, 4 hours for a fully customized theme is pretty quick. In 2.x, it probably would have taken days.

Anyone want to tackle creating their own theme for ExtJS 3.0? Here’s the basics:

1. Open your ExtJS 3.0 folder, and go to /resources/css/
2. Make a copy of “xtheme-blue.css” and name it whatever you’d like. (e.g. “xtheme-mytheme.css”)
3. Go to the /resources/images/ folder.
4. Make a copy of the “/default/” folder and name it whatever you’d like. (e.g. “/mytheme/”)
5. Open your new CSS file.
6. Find/Replace all references to “../images/default/” with the path to your new images folder. (e.g. “../images/mytheme/”)
7. Include your new CSS file in the header of your webpage.

At this point, you have a new theme… albeit an exact copy of the standard “blue” theme. Now it’s just a matter of changing colors in your CSS file and Photoshop-ing the images in your new “/mytheme/” folder.

Granted, I’m making this sound easier than it actually is. Photoshop-ing the CSS sprites and background images is still a tedious process – and if you’re not a Photoshop wizard, it can be pretty frustrating. That being said, I’ll leave the rest of the details as an exercise for the reader. . . besides, the whole point of making a custom theme is to do whatever you want with it. My input beyond this step is really irrelevant.

If anyone out there attempts to create their own theme I’d love to hear your thoughts!

With more than nine million Google search results for the phrase “javascript prototype inheritence” you would think that it would be easy to find an explanation that was both (1) easy to understand and (2) technically correct. In this case, you’d be wrong.

Douglas Crockford has an explanation which is technically correct but uses examples which aren’t very clear (in my opinion). Wikipedia has a nice generic explanation of prototypal inheritance, but it’s not JavaScript specific and has no technical examples.

After a good deal of searching I found a blog post by Sergio Pereira that was far and away the best article I read. While technically spot-on, Sergio’s diagrams and example code set his post apart from every other article I’ve read. I highly suggest subscribing to his RSS feed as Sergio also has a host of other great JavaScript tips.

After speaking with oxxxymoron (the project owner, aka Andrey Zubkov) I have agreed to join the project and help update the Wiki documentation. Granted, this isn’t a glamorous job – but I think every JavaScript developer should use Ext-Doc. In order to attract more users, the Wiki desperately needs updates as it currently isn’t that helpful.

Over the next few weeks, I’ll be adding examples and explanations so that using Ext-Doc is easier to get running.

Ext-Doc is a JavaScript documentation tool which creates by far the best looking documentation. Created and maintained by several members of the ExtJS community, Ext-Doc outputs your documentation using a template mimicking the ExtJS documentation. The tool is compatible on both Windows and Mac/Linux (it runs off Java) and fairly easy to setup.

So far, I’ve only encountered three issues:

1. The instructional Wiki on Ext-Doc site (hosted on Google Code) is simply terrible. It’s clear that the focus has been on developing the tool itself, but there’s close to zero documentation supporting it. If you need help, you have to search the ExtJS message boards.
2. The documentation output by the tool cannot be viewed locally – it must be uploaded to a server as it relies on Ajax.
3. The documentation tags are different from some of the other JS documentation tools

The first issue is obviously frustrating, particularly as the Java JAR file will hit errors and give you no reason why anything fails. Searching through the ExtJS forum and talking with the community has helped me get started, but this is a huge flaw and is (in my opinion) preventing Ext-Doc from being the defacto JavaScript documentation tool available. If they can get their Wiki up to date then this tool will certainly make an impact.

The second issue is actually pretty easy to work around on Microsoft Vista. Since Vista comes packaged with IIS7, you can simply tell the .BAT file to output the documentation to your local host’s root. This way, you can update and view your docs without having to copy/paste or FTP files to a web server.

Lastly, the tags used to document your JavaScript code are different in Ext-Doc than in JSDoc Toolkit (which is what I had been using). I don’t know if either tool is actually consistent with documentation standards in JAVA, but I wish that all of these JavaScript tools would use the same set of tags. It would make testing other tools much easier, and consistency in documentation is really important. Douglas Crockford (if you’re reading this), can we PLEASE get this discussion in front of the ECMA Standards board?

At the very least, I’m biased towards this new Ext-Doc tool (not really so new, actually) because I use ExtJS and I love their documentation. Once I get my tags updated, I think I’ll be very happy with this tool.