Book Excerpt and Interview: ExtJS in Action
The author has over 16 years experience in IT and enterprise web application development. He has deployed Ext-based applications in large corporations such as Marriott International, Lockheed Martin, JPMorgan Chase, and the Financial Industry Regulatory Authority. In his spare time, Jay enjoys assisting the Ext JS community forums, where he is one of the top posters not employed by Ext JS LLC (over 13,000 posts).
The book includes information on:
- Building dynamic UIs using core components like panels with layouts
- Creating live forms that submit data without a page refresh
- Effective UI using trees, menus, and toolbars
- Creating custom composite widgets
- Full coverage of Ext JS 3.0
The book’s publisher, Manning, made an expert available to InfoQ which includes the contents of the 3rd chapter, “The Component model and lifecycle”.
InfoQ readers can take advantage from a 40% discount on Ext JS in Action using the promo code “infoq40”, courtesy of the publisher.
InfoQ had a Q&A with the author about his new book:
InfoQ: Hi Jesus, would you like to tell us a little bit about yourself and how you came about writing a book about Ext JS?
Jesus: I began with Ext JS back in early 2006, when it was a set of extensions for the YUI library. Back then, it was known as “YUI-ext” and was developed as a side project by a little known guy named Jack Solcum. Like many newcomers to the framework, I was first attracted to the data grid. What sold me to the library was the documentation, which is probably the best Ajax framework API to date.
Soon after my introduction to the framework, I decided to become a specialist and focus my career, becoming an independent consultant. After this decision, I started becoming active in the early community, spending a lot of my own time in the help forums, answering people’s questions or working through their problems with them. By doing this, I was able to learn much more about the framework than I would by just doing application development. To this day, this still gives me a means to learn a lot while contributing to the community by helping others.
Being on the Ext JS forums has earned me a bit of a reputation, and is how I got onto the radar of Michael Stephens from Manning. He contacted me, along with other active community members, to request a review of a book proposal. After reading the first few lines of the proposed table of contents, it was clear to me that this book was not an “Ext JS in Action”. After submitting my thoughts and recommendations on the proposed TOC, Michael held a post-review meeting and that’s where he asked if I would be willing to submit a TOC of my own, and I did. Fast forward two years, and here we are.
InfoQ: What is Ext JS and what is the problem that it tries to solve?
Jesus: Ext JS is a UI library for the web. It is light years ahead of any UI library on the market because it abstracts developers from having to write a single ounce of HTML if they don’t want to, yet has the flexibility to allow any developer to Extend the widget libraries or create real plugins via a simple, yet powerful plugin architecture.
Ext JS solves the problem of managing HTML and CSS to provide a UI look and feel that rivals desktop applications. It empowers developers to inject widgets into existing HTML web pages or develop extremely rich Enterprise class RIAs, some of which are used in mission critical applications, such as real time monitoring and managing of network infrastructures.
The framework also has quite a lot of utilities, such as the data Store, templates and xTypes that further empower application development capabilities.
InfoQ: In your book you mention that the Component and Container models that Ext JS follows is what makes it stands out from the rest of the Ajax libraries. Would you like to elaborate on that?
Jesus: The Component and Container models (among other things) make Ext JS quite unique among competing Ajax libraries because they bring structure to the UI portion of the library. Without it, Ext JS would be not much different from other Ajax Libraries.
The Component model introduces the “Component Lifecycle” to the framework and brings a set of well-defined and dependable behaviors to the widgets. It is broken up into three phases, Initialization, Render and Destruction. Initialization occurs whenever you instantiate a new instance of a component. The Render phase occurs when the Component is rendered or painted on screen. Lastly, the Destruction phase allows the Component to perform cleanup tasks, such as the removal of any injected HTML nodes and purge any event listeners.
The Container model allows Components to manage other components in a parent-child relationship model. With the Container model, developers can easily create dynamic UIs by leveraging its add() or remove() methods to add or remove one or more child items. To manage the visual organization of child items, Containers use a Layout.
InfoQ: Would you like to tell us a little bit about how you use Ext JS in your work? How do you see other people using it. Are there types of RIA applications where it is not a suitable solution? Is Ext JS suitable for mobile web applications?
Jesus: I typically use Ext JS to develop applications for a wide variety of customers. My latest task was to develop a screen to manage member information for one of my customers. Because Ext JS is so versatile, I’ve been able to leverage it to develop a wide variety of applications from a custom UI merging data from IBM’s Tivoli Enterprise Console and HP Universal CMDB to a front-end for EMC’s Documentum product. I’ve even developed applications to help organizations develop content for exams.
Developers can leverage Ext JS pretty much to develop whatever they need in a RIA. Throughout its lifespan, I’ve seen such a wide range of applications, most of which were business-centric.
Ext JS, itself is not geared towards mobile web development, but its sibling Sencha Touch is. I have seen and toyed with Ext JS applications running on an iPad with limited functionality. It does not contain support for touch gestures that make mobile applications useful and its UI theme is certainly not mobile-centric.
InfoQ: How good do you see Ext JS perform on the various browser platforms? What do you have to say to people that might be reluctant to use it because of current compatibility issues, or fear to lose compatibility because of future upgrades?
Jesus: Boy that’s a loaded question (smile). I would have to say that Ext JS performs the best given the best environment to run in. Generally, it has been my experience that Ext JS runs best in Webkit-based browsers, and absolutely the worst in IE. Naturally, the browser has a lot to do with this perception, but there were some issues in the early release of the Ext JS 3.0 code base that contributed to the slow performance in IE.
It’s a known fact that general performance for the initial release of Ext JS 3.0 was much less than 2.x, but it certainly has gotten better with subsequent releases. The Ext JS team has been pretty sensitive to the feedback that various customers and community members have been giving them and have been making necessary changes to try to squeeze as much performance as possible without limiting functionality.
Upgrading from the 2.x branch to the 3.x version is pretty easy. This also holds true with upgrading within the 3.x family. From my experience, most of the problems people have with upgrading is that they have code that are depends on, uses or overrides private members, which are subject change. They are marked private for a reason. Obviously, this practice is not recommended by the team or even by veteran developers and is something you should work to avoid to allow for easier upgrades.
Jesus: I typically develop applications locally on my laptop to make the feedback loop as rapid as possible. I use a pattern to developing applications following the framework’s patterns, with somewhat of a twist. For instance, I like to lay out the files in the file system (and project) according to the namespace of the class. This allows for quick access to files. This same pattern is applied to any plugins, user extensions (ux) or overrides that are applied to the framework.
I’ve heard great reports from developers using tools such as NetBeans or even Aptana, which is a wrapper for Eclipse.
Jesus: It can pose serious difficulties for a lot of reasons. The first typically is that developers will use ext-all.js (concatenated and minified version of the framework) instead of ext-all-debug.js (concatenated with white space preserved and comments removed) when developing. If an exception is thrown by the JS interpreter, the message will typically be extremely cryptic due to the nature of JS minification. If the error is viewed in IE, it generally will make no sense what so ever and add to your frustration. Generally, to remedy this, you would want to develop your apps using the uncompressed ext-all-debug.js file, which will make the error message a tad less cryptic and you can at least get an accurate line indication for which the exception occurred.
Whenever an exception is generated by ext-all-debug.js, I typically will try to view the area where the exception occurred. From there, I scroll up to find the method that the exception was generated in, then scroll up again to find the class that the method belongs to. Nine times out of ten, for me at least, the problem is usually between the keyboard and the chair.
I have to say that because I use Webkit, viewing hundreds of thousands of lines of JS in the ext-all-debug.js file is a breeze. Sadly, the current state of Firefox prevents Firebug from reaching the same level of performance, which is why I moved to Webkit from Firefox a few months ago. I’ve tried the same in IE8 and ended up pulling a lot of my hair out.
InfoQ: Are you using any functional testing methods in your work? How do you go about this issue?
Jesus: Unfortunately no. I have thought about injecting unit testing into the application development cycles for my customers, however time always seems to be an issue. The amount of time spent writing tests can save you tons of time in bug fixes in the future, but making that initial investment is difficult for my customers.
InfoQ: In your book you describe several components that you get out of the box, when using Ext JS. Is it easy to extend those? How easy is it to create new components?
Likewise, you should be familiar with the Component, Container and layout models to extend widgets properly and prevent common mistakes like overnesting. Good knowledge other areas of the framework helps as well.
I bring all of this up because I’ve seen so many new developers come to the framework with grand dreams of building complex and elaborate applications. Yet they find themselves stumbling on simple tasks, all because they do not have the foundation necessary to fully understand or utilize the framework.
InfoQ: How do you see Ext JS evolving with the emergence of HTML5?
Jesus: The one thing that has been great about the Sencha team is that they are always looking ahead. They have been working hard to bring Ext JS HTML5 and CSS3 compliant for version 4.0, which is due out some time next year. Ext JS 4.0 shares the same base code as Sencha Touch, which already has great support for these technologies.
InfoQ: What do you think would be the most valuable take away from your book for people that have just found about Ext JS and what for seasoned users of this frameworks that want to take it to the next level?
Jesus: For the newbies to the framework, I think getting a deep understanding of the Component, Container and Layout models is a great take away. I tried my best to explain them in plain English as possible and have gotten pretty good feedback from readers.
For the veterans, I’d have to say that the most valuable take away from the book has to be the last three chapters (15-17). Chapter 15 gives readers the basics of creating extensions with Ext JS and developing plugins using real-world examples. The last two chapters are dedicated to constructing a fictional application and walk readers through core decision making processes, such as laying out a namespace and developing abstract classes to reduce duplicate code.
Developers from many experience levels have given me positive feedback from after reading these chapters and have said that some the concepts have helped them in various ways when developing applications.
Uwe Zdun, Rafael Capilla, Huy Tran, Olaf Zimmermann Mar 09, 2014
Olav Maassen, Liz Keogh & Chris Matts Mar 08, 2014