Implementation Spotlight:  Zipwhip and Ext JS

May 27, 2009 | Abraham Elias

With close to 100 billion text messages sent every month in the U.S., text messaging has clearly become a communication medium many of us have come to rely on. Zipwhip, a text messaging utility for the web with a polished Ext-based user interface, aims to take texting to a new level. The team at Zipwhip were eager to share their enthusiasm and approach to building with Ext.

Tell us a little bit about Zipwhip and your goals for the application.

To pull off our ambitious goals, we're using just about every web 2.0 trick in the book—comet to send carrier delivery receipts back to the browser in real-time, Ajax for server communications, download-on-demand Javascript packages (with preloading), Flash for audio notifications, and many others.

Why did you choose Ext JS?

One of the design decisions we made early on was that we wanted a rich desktop-like experience inside the web browser. We investigated the other major players in the field, but ultimately decided that ExtJS was the best. One of the things that made ExtJS especially appealing was the "Window" object that can contain "Panel" objects. Our core requirement was a windowed interface and having Ext.Window cross-browser out of the box was a major win.

Ext allowed us to focus on putting together the Ext building blocks that were engineered to be cross browser rather than reinvent the wheel. We had a limited budget and limited time and Ext provided 90% of the functionality we had in mind. We used a combination of Ext layouts and CSS to achieve many of the window structures used in the site. Theming the Ext widgets and integrating them with custom css layouts was a breeze.

Lastly, the XType architecture allowed us to create Javascript packages and download them on demand. This allows us to create an application that was not bounded by download size. A browser would have a difficult time rendering our site if not for lazy loading. What used to be a difficult custom built proposition (lazy loading) became an afterthought with Ext JS.

The Zipwhip application is extremely feature-rich. How did you manage the UI code complexity?

One of the small footnotes in Ext JS is the "plugin." We've made that concept into a corner-stone of our application. Each carrier requires different functionality, features, and different business rules. With progressive enhancement we can swap in plugins that provide different implementations of various features, and ensure we only download the plugins that are needed.

Another thing that simplified my life greatly was David Davis' (xantus) implementation of PubSub. This allowed us to decouple areas of the code, which made for a simple core framework. We implemented PubSub very late in the development process and are still working to fully take advantage of this wonderful design pattern.

Finally, keeping the code divided into standard namespaces was invaluable. We segmented common "Operating System" level widgets into Zw.controls and put all of our Ext.data.Records into Zw.data. Namespacing the code kept things manageable.

Oh yeah, and one class per file. Nobody likes a 10,000 line file.

What other techniques did you use to achieve such a gorgeous UI?

Most of what you see in the Zipwhip application is standard Ext JS with some fancy css overrides. We were surprised how easy it was to add some custom graphics to the existing Ext JS markup.

Ext.layout

One of the most awesome things about Ext JS are the Layouts! Because of the amazing flexibility we could mix css and Ext layouts to give us the desired effect with minimal code. The FormLayout (with anchoring) can manage the position of the fields, whereas CSS could manage the complexity of the Phone Preview Area.

Also Ext JS layouts improve performance and page weight. Specifically the layouts each decide when to render the content they are responsible for. This means that the Threading tab is only rendered the first time the user views the tab.

Ext.menu.Menu and Ext.DataView

Ext.menu.Menu (and the Adapter) became one of the handiest components in the ExtJS library. All of our Right-click menus were implemented with the Ext.menu.Menu. We host panels inside the menu and use a combination of CSS trickery plus Ext layouts to get the resulting effect.

Possibly the part we used the most out of Ext was the Ext.DataView. In the Contacts window (and Corkboard), we utilize an Ext.DataView and customized it to allow rendering of Ext.Components. The DataView abstracts away the difficulty of managing a list of Widgets linked to a Ext.data.Store.

Ext.SplitButton

The ContactCard (Zw.controls.ContactCard) extends the Ext.SplitButton. I know our ContactCard doesn’t look anything like a split button, but it truly was the best approach. Thanks to the way that Ext designed their components, we were able to easily modify the Template that is used to generate the button. Also thanks to the xtype, delay rendering, and plugin model the API was extremely simple.

items: {
xtype: 'Zw.controls.ContactCard',
closable: true,
plugins:  [
"Zw.controls.ContactCardEditNamePlugin",  //enable it to be editable
new Zw.controls.ContactCardDropdownPlugin(), {  // allow right clicks on the card
xtype: 'Zw.controls.ContactCardPopupPlugin'  //pop it up if its too small
}],
listeners: {
scope: this,
'close': this.onContactCardClose,
'rename': this.onContactCardRename
}
}

What features could we add to Ext to make building a rich application like Zipwhip easier in the future?

We had the situation where we needed to create an Ext.DataView that displays Widgets. Currently you can only use an Ext.DataView with an Ext.Template. A solution that allows for controls to be created and inserted according to an Ext.data.Store would be valuable.

Additionally, "best practices" for preventing and dealing with memory leaks would make building an RIA easier. Memory leaks with templates, dataviews, and elements can cripple the development process if not planned for.

Do you have any advice for developers using Ext for the first time?

Final thoughts?