Slashdot videos: Now with more Slashdot!

View

Discuss

Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

dulepov writes "An extensive set of features makes ExtJS a very popular framework. But a rich set of features comes with a cost: the framework is complex. While many frameworks can be learned from source, with ExtJS this is not the case. Syntax of object-oriented programming in JavaScript can be very difficult to understand and ExtJS sources demonstrate that. As a practical programmer, I think that the best way to learn ExtJS is to read a good book and follow examples inside.The ExtJS book I got was published by Packt Publishing. It is called Learning ExtJS 3.2. I consider myself an experienced ExtJS developer but there are always more experienced developers and this book was written by several of them." Read below for the rest of dulepov's review.

Learning Ext JS 3.2

author

Shea Frederick, Colin Ramsa, Steve 'Cutter' Blades, Nigel White

pages

432

publisher

Packt Publishing

rating

9/10

reviewer

dulepov

ISBN

1849511209

summary

A good learning resource about ExtJS

tester dataWhen I looked through the table of contents, I realized that it is one of those rare books that suits all kind of readers: from beginners to advanced. The book starts from "Getting ExtJS" chapter. It discusses why ExtJS is different, how to get it, where to put it, etc. While this may seem like a chapter for beginners, I read it with interest and found several tips I will use in my next project. The opening chapter also tells what to do if the developer sees error messages. This is another advantage of the book: it is highly practical.

Further chapters describe how to use ExtJS. Here is what is covered: getting elements, creating and using forms, working with menus and toolbars, displaying and editing data with grids, using layouts for components (you can quickly rearrange objects by just applying another layout), creating tree controls, using windows and dialogs. There are also chapters about charts, effects and drag-and-drop. In addition there is a chapter about extending ExtJS. This area is probably one of the most difficult for programmers because this is not what the developer can find in the ExtJS package. The topic about extending ExtJS takes 38 pages, so it is really well covered.

Another interesting topic discussed in the book is data transfer between the browser and the server. There are traditional ways (such as AJAX) but ExtJS and the book go further discussing remote method invocation from the client on the server using ExtDirect. ExtDirect is a hot topic in the ExtJS community because it greatly simplifies communication between the client and the server. Thus the developer can save development time.

The final chapter in the book talks about useful additions to ExtJS such as HTML editor, state management on the browser side, using AIR, etc. It also describes several community extensions to ExtJS (such as TinyMCE and SwfUploadPanel) and how to use them.

The book contains a lot of examples, so the reader can learn through them. One side note here (and a recommendation to Packt editors): I found that spacing in the examples could be smaller to avoid line wraps. Reading examples would be easier if the spacing was reduced. Truly speaking, this is the only bad thing I can tell about the book.

Despite being experienced in ExtJS and using it since version 1.x, I found a lot of good tips in this book. It is really useful and now lives on the shelf among good programming books. So if you need a good learning resource about ExtJS, I can definitely recommend Learning ExtJS 3.2 .

P.S. Current version of ExtJS at the time of writing of this review is 3.3.1. That does not make the book obsolete at all.

I have a hard time with any educational or technical material which claims to be appropriate for everyone from beginners to advanced. If you cover that much material, your book is either several thousand pages long or you are probably not truly serving at least one of the ends of the spectrum.

I have a hard time with any educational or technical material which claims to be appropriate for everyone from beginners to advanced. If you cover that much material, your book is either several thousand pages long or you are probably not truly serving at least one of the ends of the spectrum.

Or laser focused on one tiny little thing...

Next up on/., "Learning printf on GCC 4.1.1" in 432 pages

Current version of GCC at the time of writing of this review is 4.4.5 assuming you use Debian Stable. That does not make the book obsolete at all.

If you have libraries (jquery, mootools, prototype, etc) and frameworks (cappuccino, sproutcore, google's gwt, etc), then ext is somewhere in the middle. I think it started as an extension to YUI, but now it can be used on top of prototype, jquery, YUI, or its own base library.

Why buy a book on 3.3.1 when the API and (preview) code for 4 is already out? By the time you've learned 4, the stable release will probably already be released. That's the problem with technical references that are printed in hard copy - they take too long to get to market and can't be updated like references on the net.

If you know ExtJS, you'll know that the API has remained pretty stable and constant since 2.0. (I've been able to port my code from 2.2 to 3 with almost no changes, for instance.) Not to mention that when web applications are developed with a specific version of framework like ExtJS in mind, they tend to stay frozen to that particular version (if it ain't broke, don't fix it, etc.). I can definitely see how this particular book could still be useful years from now.

In what category of animal does ExtJs fit vs. jQuery combined with jQuery UI?

jQuery has basically broken away from the pack [google.com] from other Javascript toolkits/frameworks/libraries. (Which is not to say they all have the same purpose.)

When you've got a lot of players in the field, and have to decide what to use, and are also thinking about new devs already being familiar with a package, going with the market leader seems to be what most people will do.

I use 'em both all the time. If I'm coding a web app (or even a new page in an existing web app) from scratch, I'll use Ext. Once you wrap your head around OOJS and Ext's API, it's widget set is far easier to use and more consistent than jQuery. OTOH, if you are enhancing and existing page, then jQuery is tops. There are even times when *gasp* I use 'em both on the same page. No, you don't want to be loading lots & lots of library code, but for apps that don't go over the internet, and are used within a

Mostly because the philosophy of jQuery seems to be embracing CSS and the DOM, rather than abstracting them away. It often feels like the API that was missing from the W3C spec.

The other, bigger reason I personally have been avoiding EXT is the attitude of the core developer(s) about the GPL -- in particular, they not only switched to the GPL lately, but they have a fairly perverse understanding of the GPL which suggests that using EXT would to build a frontend would require me to open source my entire back

This may have changed recently, but I distinctly remember having to strip EXT from a commercial product simply because we could not afford to either be stuck with an old version of a framework or pay licensing fees for a javascript toolkit.

What's worse, they went from not requiring that to requiring it, and they demanded more than the GPL asks for. In particular, they decided that the entire application included both the frontend and the backend. It probably wouldn't have been OK for us to GPL our frontend either, but both frontend and backend was out of the question.

Note that this disallows quite a lot of things which would otherwise make sense. For instance, if I develop some sort of backend-agnostic fron

I know you're an AC, and maybe I'm foolish to expect more, but your main point:

If you want to keep your product closed, buy a damn license.

I answered in the post you're replying to:

we could not afford to either be stuck with an old version of a framework or pay licensing fees...

This point is even more asinine:

I've never understood why people complain that something is not free and open when they want to build closed and non free products.

The complaint isn't that it's "not free and open", it's that it's problematic for non-GPL'd stuff, proprietary or otherwise, and even for GPL'd software which wants to connect to non-GPL'd servers. Presumably you have no problem with the fact that your web browser, whatever its license is, can connect to a server running non-free code? Would you prefer it d

It comes in two parts, a 'base' and the rest of it. The default base can be swapped out for jQuery (or a couple of other JS libraries) via an ExtJS 'adapter' which deals with various things including namespace issues, so use of both jQuery and ExtJS is officially blessed.

We evaluated a few others, but ExtJS's widget set seemed more comprehensive. (The killer at the time for us was a robust tree control supporting drag and drop.) Having used it for a while, it is fairly c

The $ and css-based selector syntax of jQuery makes it highly welcoming for devs that have to learn Yet Another Library.

God, really? The worst decision the designers of jQuery, Mootools, etc made was to all decide to use $ as their base object. There's no reason why the couldn't just call it jQuery instead, but they had to go and use one character that everyone else also decided was so cool that they would use that for everything they did too, and now everything either overwrites each other or you need to use alternative methods to access it. They should have just named their objects in a meaningful way in the first place

Which itself is only marginally worse than jQuery(jQuery.jQuery).jQuery

Not exactly the most welcoming type of thing for a new user. Is it a function? Is it an object? Is it a property? Yes!

It's like they only did it for the novelty of the thing, not because it's useful in any way. My CSE 100 classes taught the benefits of meaningful variable names. These guys must have skipped the intro classes.

The topic about extending ExtJS takes 38 pages, so it is really well covered.

Well, if more pages == more good, then I guess I ought to go looking for an even bigger book!:)

I would have loved to know what it is in those 38 pages that cover the topic of extending ExtJS well. Even basic info about the 38 pages (it walks you through a single example in detail over 38 pages; it starts with a small example & builds on it over 38 pages; it covers sub-topics X, Y, and Z in detail (and X,Y, and Z are particularly important/difficult to do/etc), or whatever) would help me know if this b

I know this is "News for Nerds", but you know what would have made this post better? A 1-sentence description of what ExtJS means. Sure, I figured it out from context that "JS" meant "JavaScript", but what's the "Ext" indicate? "Extended"? "Extensions"? Is ExtJS part of the JavaScript standard that every browser includes? Why should I care about ExtJS?

At the very least, include a link to the ExtJS [wikipedia.org] entry at Wikipedia. (At least, I assume that's the right link?)

Yes, it has a lot of features. But no, it doesn't scale well when what you need is granular control of how javascript loads and executes, and it doesn't help multiple developers working on different modules. Lots of hardcoded references to global objects, long namespaces, HUGE file downloads. It just doesn't add up. Sencha needs to really step up if it wants to stay competitive with a paid product.

Way better alternatives are YUI3 [yahoo.com] and GWT [google.com]. Even ideas such as Wijmo [wijmo.com] perform better.

I agree to an extent. I ended up ditching ExtJS and rolling my own editable grid, server communication, popups, etc.
Of course, I had very specific "low level" (if one can even say that for JavaScript) requirements for functionality and render optimization.
ExtJS is great for getting a UI up and running quickly.

I only spent 10 seconds looking at the website of ExtJS' producer, Sencha.
But... the first thing I noticed is that ExtJS is available both as open source, and as a commercially licensed product that one pays for.
Errrr... OK. So, which is it? Frankly, any software product that is available as both open source and as a commercially licensed product is... well, it's scary. The last thing I want is an "open source" framework where the producing company has the ability to pull the rug out from under me a

Thanks for the great review. I'm really glad you enjoyed the book, and especially that you were able to get something tangible to use. It's great to see that kind of feedback. When I first started learning Ext JS there weren't any books out there. I spent hours reading through the demo code, and combing through the forums. When Packt contacted me to help complete the first book I jumped on it, knowing that there were other developers out there like me that would learn more (and faster) from a b