The table layout gives you complete control over how you want to visually organize your components. Many of us are used to building HTML tables the traditional way, where we actually write the HTML code. Building a table of Ext Components, however, is different as we specify the content of the table cells in a single dimension array, which can get a little confusing. Once you’ve done these exercises, you’ll be an expert in this layout.
Manning has also given us the discount code “ajaxian35? that gives you 35% off of any version of this book. So, if you like what you see in the excerpts, get it cheap!
Bill Scott presented Designing Web Interfaces, a slideshow based on core items from his book (co-authored by Theresa Neil).
There are some really interesting posts on the site, such as 30 Essential Controls. Theresa has been pinging the major frameworks and will be posting a matrix of coverage by the various frameworks. But more generally it is a nice checklist of controls that can liven up an interface.
Usability and design guru Luke Wroblewski knows that web forms suck. More importantly, he knows why – and how to make them suck less.
For the past few years, the Yahoo! product design exec has been presenting his ongoing research into the humble HTML form at conferences and on his blog, Functioning Form. I attended Wroblewski’s presentation at An Event Apart Chicago 2007 and came away super-impressed. His persuasive mixture of case studies, existing research and newly commissioned usability studies helped shed light on the patterns and anti-patterns that determine whether users successfully complete your forms or give up in disgust.
All of Wroblewski’s preparation came to fruition earlier this year when he published “Web Form Design: Filling in the Blanks” (Rosenfeld Media). After finally taking the time to read the book cover to cover, I’m mad at myself for waiting so long.
This content introduces the closure, an important aspect of JavaScript, and describes its use. It goes into detail on making private data, and dealing with callbacks and timers.
Next up introduces the construct (function(){})() and describes its use in relationship to closures. See how you can create encapsulated temporary scopes.
I heart David Flanagan. I’m making my way through “The Ruby Programming Language” this summer. Its exhaustiveness really satisfies. But a decade ago, my programming Bible was Flanagan’s “JavaScript: The Definitive Guide”. As I transitioned from a career in content to a career in code, “the Rhino book” taught me everything I needed to know about object-oriented JavaScript, DOM scripting and the other building blocks of today’s Ajax landscape. I’ve bought a hard copy of each of the book’s five editions. It remained, until recently, the only JavaScript book I’d recommend.
That all changed with the recent publication of JavaScript: The Good Parts by Yahoo’s Douglas Crockford. Crockford probably needs no introduction. His incisive website and frequent blog posts have championed JavaScript’s power and potential while calling out its drawbacks and frequent misuse. Now, with “JavaScript: The Good Parts,” he has managed to provide a reference as useful for JavaScript pros as it is for novices. Part language primer, part apologia and part critique, Crockford’s book draws from and extends many of his long-gestating themes about how to use JavaScript – and how not to use it.
The author’s premise is so simple and intuitive that it sounds like rubbish until you suddenly realize that this is how all programming languages should be taught:
When I was a young journeyman programmer, I would learn about every feature of the languages I was using, and I would attempt to use all of those features when I wrote. …
Eventually I figured out that some of those features were more trouble than they were worth. Some of them were poorly specified, and so were more likely to cause portability problems. Some resulted in code that was difficult to read or modify. Some induced me to write in a manner that was too tricky and error-prone. And some of those features were design errors. Sometimes language designers make mistakes.
Most programming languages contain good parts and bad parts. I discovered that I could be a better programmer by using only the good parts and avoiding the bad parts. After all, how can you build something good out of bad parts?
By now, you’re almost certainly familiar with Ajax as a buzzword. Technically, it’s an acronym—Asynchronous JavaScript and XML — and refers specifically to JavaScript’s XmlHttpRequestobject,which lets a browser initiate an HTTP request outside the confines of the traditional page request.
Yawn. The technology isn’t the exciting part. Ajax is huge because it pushes the boundaries of what you can do with a web UI: it lets you reload part of a page without reloading the entire page. For a page-based medium like the Web, this is a seismic leap forward.
The chapter delves into the world of Ajax.Request, Ajax.Updater, Ajax.PeriodicalUpdater, by showing subtle examples of how to deal with timers, errors, and a lot more.
Craig Riecke, Rawld Gill, and Alex Russell, along with the Pragmatic Programmers themselves have been kind enough to give the Ajaxian community some exclusive extracts from the Mastering Dojo beta book.
What do we have on the docket?
First, we have details on the Dojo DOM Apis. Specifically, the author takes us through a challenge involving interview questions and manipulating the DOM for them. We end up seeing code that uses dojo.query, and class addition such as:
dojo.addClass(node, (i % 2) ? "lightBand" : "darkBand");
});
}
It then delves into the intricacies of dojo.query and beyond.
Secondly, we have Ajax the Dojo way which takes us on a trip down dojo.data and dojox.Grid lane... two differentiating features that Dojo comes with. The chapter builds a wishlist system using these features.
There is a lot lot more in the book, which the table of contents covers for you. There are 400 pages of material here that cover the huge variety that exists within the Dojo community.
Thanks to the authors and the editor for sharing this with us.
Douglas Crockford has an interesting book on the horizon, JavaScript: The Good Parts. When I first heard about the combination of author and title, I couldn't help but think that it would be a short book, maybe a two pager as above.
But, Douglas has taken a deep look and found some content worthy of a book:
Most programming languages contain good and bad parts, but JavaScript has more than its share of the bad, having been developed and released in a hurry before it could be refined. This authoritative book scrapes away these bad features to reveal a subset of JavaScript that's more reliable, readable, and maintainable than the language as a whole-a subset you can use to create truly extensible and efficient code.
Most programming languages contain good and bad parts, but JavaScript has more than its share of the bad, having been developed and released in a hurry before it could be refined. This authoritative book scrapes away these bad features to reveal a subset of JavaScript that's more reliable, readable, and maintainable than the language as a whole-a subset you can use to create truly extensible and efficient code.
Considered the JavaScript expert by many people in the development community, author Douglas Crockford identifies the abundance of good ideas that make JavaScript an outstanding object-oriented programming language-ideas such as functions, loose typing, dynamic objects, and an expressive object literal notation. Unfortunately, these good ideas are mixed in with bad and downright awful ideas, like a programming model based on global variables.
When Java applets failed, JavaScript became the language of the Web by default, making its popularity almost completely independent of its qualities as a programming language. In JavaScript: The Good Parts, Crockford finally digs through the steaming pile of good intentions and blunders to give you a detailed look at all the genuinely elegant parts of JavaScript, including:
Syntax
Objects
Functions
Inheritance
Arrays
Regular expressions
Methods
Style
Beautiful features
The real beauty? As you move ahead with the subset of JavaScript that this book presents, you'll also sidestep the need to unlearn all the bad parts. Of course, if you want to find out more about the bad parts and how to use them badly, simply consult any other JavaScript book.
With JavaScript: The Good Parts, you'll discover a beautiful, elegant, lightweight and highly expressive language that lets you create effective code, whether you're managing object libraries or just trying to get Ajax to run fast. If you develop sites or applications for the Web, this book is an absolute must.
Combine this with John Resig's new book, and we have some good stuff to look forward too.
The server-side portion of "Advanced Ajax" uses PHP code to illustrate its many and varied lessons about Ajax architecture. It's not that I have anything against the popular web-development framework and scripting language. It's just that, after spending my career in the ASP Classic and JSP trenches and slowly ramping up on Rails in the last year, I'm not the ideal target audience for these code samples. Adding "PHP" to the title of the book might have limited its potential audience, but it also would have been more accurate.
That said, there's a lot of value here for adherents of any server-side framework. Lauriat discusses each topic from a general perspective before diving into the code. The technical approach to a given problem would obviously differ by framework, but the high-level approach wouldn't. If you don't mind skimming past the content that doesn't apply to you, Lauriat's advice about developing stable, scalable, accessible and secure Ajax applications transcends framework allegiance.
Because Ajax moves so much application logic from the server to the client, it forces many developers to master a wider range of web technologies than ever before. To work effectively on Ajax projects, front-end developers have to concern themselves with database performance, business logic and other server-side concerns. Back-end and middleware developers, meanwhile, have to make friends with XHTML, CSS, JavaScript and a wide range of browsers. Sure, it's possible to develop Ajax apps in a siloed team environment. But it's not the easiest way, and it rarely provides the strongest results.
Shawn M. Lauriat's "Advanced Ajax: Architecture and Best Practices" (Prentice Hall, 2008, 360p) bridges the gap between developers with exclusive client- or server-side skills. By exploring tools, technologies and best practices for every layer of the Ajax programming model, this solid new programming manual promises to plug the holes in any developer's resume. Lauriat's tops-to-tails approach offers something for almost any developer, but it also guarantees most readers will find some sections remedial. As this two-part review will demonstrate, that's not necessarily a liability.
Ajax represents a brave, new(ish) world of web development where coding on the client is just as important as on the server side. Hundreds of libraries exist that purport to make it easier for you, and there’s always the "Do It Yourself" approach. Which route should you take?
If you work with Java technologies, one choice that stands out is DWR, or Direct Web Remoting. With DWR, JavaScript-based client code that calls server-side objects works as if it were all running in the same process space. The simplicity and power DWR blends together has few rivals today.
In this, the first DWR book to be published, you’ll be introduced to DWR and all it has to offer, including reverse Ajax, XML and annotation-based configuration, container-managed security, simple POJO-based development, and greatly simplified client-side coding. You’ll learn by doing as you explore six fully functional applications including the following:
A webmail client for remotely accessing your e-mail accounts
A wiki for collaborative efforts
A file manager for remotely managing your server’s file system
A portal for enterprise reporting needs
A project management/time-tracking system
Even a fun little game!
In addition to DWR, you’ll also see how other popular libraries help realize the RIA/Web 2.0 vision, including Spring, Hibernate, dHTMLx, DataVision, Freemarker, and Ext JS. If you're doing RIA development in Java, DWR is for you, as too is this book.
(and if you like sci-fi and pop culture references strewn throughout your reading material, and a touch of wise a**-edness too, you're in for a good time to boot!)
Marijn Haverbeke has put together an online book titled Eloquent JavaScript that not only has some nice content, but incorporates an integrated interface for editing and running example programs.
Reviewers overuse the phrase "required reading," but no other description fits the new book "Ajax Security" (2007, Addison Wesley, 470p). This exhaustive tome from Billy Hoffman and Bryan Sullivan places the specific security concerns of the Ajax programming model in historical perspective. It demonstrates not only new security threats that are unique to Ajax, but established threats that have gained new traction in the Web 2.0 era. It then details both the specific technical solutions and - more importantly - the mindset that are necessary to combat such threats.
Because so many developers have historically overlooked the importance of security, the authors approach their topic for what it is: a remedial subject. They take pains to explain the basic mechanisms by which hackers have exploited insecure web applications over the last decade: cross-site request forgeries, denial of service attacks, cross-site scripting and SQL injection. Then they explain how those mechanisms have changed thanks to the rise of xmlHttpRequest, public APIs, mash-ups and aggregators. If you've ever read a Douglas Crockford rant about the "brokenness" of the web security model and wondered why the guy was such an alarmist, Hoffman and Sullivan are only too happy to provide you with a much-needed wake-up call.
What is (function(){ })() and why is it so fundamentally important to modern JavaScript development?
What does with(){...} do and why is it so useful?
How can arguments.callee change how I work with JavaScript code?
How exactly do timers work and how can I best use them?
How do I identify and tackle memory leaks in web applications?
How do I write a cross browser way of...
Getting/setting attributes.
Injecting HTML strings.
Getting/setting computed css values.
Managing DOM events.
Writing a CSS selector engine.
Doing smooth animations.
How can I use verification tools (like JSLint) to my advantage - and write my own?
What's the best way to transmit JavaScript files?
How do I write my own JavaScript compressor (like Packer)?
This looks like good stuff. I am sure the likes of Dean Edwards, Neil Mix, Kris Zyp, Alex Russell, and many others have interesting things to add.
A book that I would love to see is the equivalent of the Eric CSS books for Ajax. Take some real apps and build them in a book. Quality case studies that teach you a lot, in a nice glossy set of copy that makes you smile.
What would you like to see? Maybe the entire piece could be made collaboratively :)
They cleaned up, and 1.6 is a really nice piece of work. A lot of little nit-picks are now solved, and you are left with the lean mean machine that you know and love.
Highlights
Ajax transport objects are now automatically wrapped in an Ajax.Response object.
Ajax.Response includes support for accessing JSON response bodies as JavaScript objects via the responseJSON property.
The class API now includes full support for inheritance and superclass method calls. (See Mislav’s tutorial for more info.)
Class objects now have an addMethods method for adding instance methods after creation.
Elements can be created easily with the new Element(...) syntax.
Element#insert provides a unified API to DOM element and HTML fragment insertion.
Element#select is an alias for getElementsBySelector and is now the preferred way to find elements by class name.
Element#wrap lets you easily wrap an element inside another element in place.
Enumerable methods on Array are now backed by native Array#forEach implementations when possible.
Enumerable now has aliases for equivalent JavaScript 1.6 Array methods, and support for JavaScript 1.6’s context parameter for automatic callback binding.
Enumerable#grep now calls the match method on its first argument, so you can use it to e.g. filter an array of DOM nodes by CSS selector.
Event objects are now automatically extended with instance methods, so you can write e.g. event.stop() instead of Event.stop(event).
Prototype’s event API now supports firing DOM-based custom events with Element#fire.
The new dom:loaded custom event fires when the entire document has loaded and is ready for manipulation.
Function#curry allows for partial application of function arguments.
Function#wrap facilitates simple aspect-oriented programming and provides the basis for Prototype’s superclass method call mechanism.
Function#delay delays invocation of the function by the given number of seconds.
Function#defer schedules the function to run as soon as the interpreter is idle.
The Hash API has changed, and you must now use Hash#get and Hash#set instead of directly accessing properties on Hash instances.
String#interpolate is a shortcut for instantiating a Template from the string and calling evaluate on it.
Object properties can now be used in template replacement strings.
Script.aculo.us 1.8
This is the last release before 2.0 comes out and features:
Complete rewrite of Ajax.InPlaceEditor and Ajax.InPlaceCollectionEditor
Full CSS inheritance in Effect.Morph
New core effect: Effect.Tween
Sound: play mp3 files for sound effects; uses native playback on IE and available plugins whereever possible
Duration and distance options for Effect.Shake
Performance improvements
Tons of bugfixes
The Book (Reviewed by Stu Halloway)
The skinny: If you develop with Prototype and Scriptaculous, you need
this book.
Prototype and script.aculo.us: You Never Knew JavaScript Could Do This! is a long book, by Pragmatic Press standards. At first glance,
this might seem doubly odd, since the libraries themselves are quite
small, totaling only in the 100s of KB. But before I even opened the
book, I hoped that the length might be justified, for two reasons:
Prototype and Scripty (hereafter P&S) are packed with dense,
expressive, beautiful code, and they can do far more than their size
might suggest.
Along with several other Ajax libraries, P&S embody a modern
JavaScript style that embraces functional programming. This new style
is not well covered in the JavaScript books currently in print (as of
November 2007), so to learn P&S you also have to learn to think about
JavaScript in a new way.
Once inside the book, I was delighted to find that both of my hopes
were addressed. Porteneuve dives straight into the deep end,
embracing JavaScript's functional style immediately in Chapter 2 and
never dumbing down the example code. (Don't worry, there are forward
and backward references to help you along. This is especially nice if
you are reading the electronic copy of the book.) You may need to
read some sections of this book multiple times, and that is a good
thing.
The coverage of both Prototype and Scriptaculous is thorough. Of
course the marquee features receive due attention: Prototype's
Ajax.Request and Scriptaculous's Effects each have their own
chapters. More interesting to me is the thorough coverage of the less
visible parts:
Prototype's functional capabilities are significantly enhanced for
the 1.6 release. Chapter 4 shows how to use curry, bind (including
multiple argument invocation), delay, and defer. You can even do some
lightweight Aspect-Oriented Programming (AOP) with the new wrap method.
Chapter 7, "Playing with the DOM is Finally Fun", nicely mixes
tutorial and reference. The Staff Manager example motivates each
section, but each individual section also acts as a reference for a
set of DOM extensions.
The Event mechanism has been rewritten and enhanced for Prototype
1.6. Chapter 6 covers the new unified event handling. Porteneuve
motivates the event model by contrasting three approaches: the IE
way, the standards way, and the Prototype way. With 1.6, portability
improves again with synthetic events that fill gaps in the browser
event model, e.g. dom:loaded. You can even fire and respond to your
own custom events.
I have been using Scripty for years and I never even noticed the
sound API (Chapter 20).
Of course, no reviewer feels complete until a few nits have been
picked. So here are a few:
Porteneuve embraces Prototype's approach to JavaScript and the web
(as do I). That said, there are many other approaches. It would be
great to have an overview of the philosophical differences that set
P&S apart from other JavaScript libraries.
The book's style is casual, even by Prag standards.
Prototype and Scriptaculous are a rich buffet, and the book
documents nearly every bite. Sometimes the book could be more
opinionated about the menu. For example, I hate the $break feature in
Prototype. Maybe Porteneuve does too--the example is certainly
contrived.
These flaws are relatively minor. Overall I was impressed by the
amount of information in the book. I have been using P&S for years,
and I learned something new in almost every chapter.
For years, developers at software conferences have asked me "What is
the best way to learn Prototype and Scripty?" Until today, my answer
has always been "Read the source code." Not any more. If you are
building applications with P&S, you need to read this book.
I heart David Flanagan. I’m making my way through “The Ruby Programming Language” this summer. Its exhaustiveness really satisfies. But a decade ago, my programming Bible was Flanagan’s “JavaScript: The Definitive Guide”. As I transitioned from a career in content to a career in code, “the Rhino book” taught me everything I needed to know about object-oriented JavaScript, DOM scripting and the other building blocks of today’s Ajax landscape. I’ve bought a hard copy of each of the book’s five editions. It remained, until recently, the only JavaScript book I’d recommend.
Back in February, 
