Outside the Box() » Programming

Tuning Your ExtJS Theme

Tim — Sun, 11 Jul 2010 18:49:05 +0000

ExtJS is my favorite JavaScript favorite. The guys at Sencha have done an excellent job at building the best JavaScript framework for building intranet RIAs. The only flaw of ExtJS is the lack of themes. Although the provided blue and gray themes are very nice, after looking at them for two years you start to long for more variety.

There have been some attempts to theme ExtJS. Extthemes has built a pretty nice collection of commercial themes, but sometimes all I need is a little bling without the need to completely re-theme the framework. For example, on a recent project, I’m starting to introduce ExtJS and am making use of the Ext.Panel widget for laying out div elements.

Here’s what a basic Panel looks like in ExtJS:

And here’s the code I used to create the panel:

var panel = new Ext.Panel({
      width: 200,
      height: 200,
      title: 'Test Panel',
      renderTo: 'box'
});

I’ve got a div specified in the HTML like this

which is where the Panel is being rendered to. This is very nice if your site’s look-and-feel is baby blue, but this won’t cut it if you need a different color scheme. Fortunately, Panels are extremely easy to stylize through some simple CSS overrides.

The first step is to decide what color you need for the Panel’s header. The default theme uses a gradient image, which looks better than just specifying a background color. Gradients are pretty easy to created in Photoshop, but you can get a very nice gradient that exactly matches your needs by taking advantage of the Themeroller tool for JQuery UI. Use the Header/Toolbar customization and choose the color and gradient effect you want for the header.

After you have the header just the way you want it, download the whole theme bundle, extract it someplace and copy the image file for the header into your project directory.

There are three CSS selectors you need to override to apply your customization to the Panel. They are .x-panel-header, .xpanel-header-text and .x-panel-body. For my example, I just borrowed the header image for the Eggplant theme and configured these selectors to produce the following:

Here is what I specified in my CSS file to override the default style:

.x-panel-header {
  background: url(resources/images/eggplant.png) center left repeat-x;
  text-align: center;
  border-color: #000;
}
 
.x-panel-body {
  border-color: #000;
  background-color: #fafad2;
}
 
.x-panel-header-text {
  font: bold 14px Consolas, Arial, san-serif;
  color: #eee;
}

In the .x-panel-header selector, I specified the background to be the header image I got out of the Themeroller theme. For a little added bling, I changed the text alignment to center the text and set the border color to black. Note, I renamed the gradient image from the cryptic name Themeroller created to eggplant.png.

For the .x-panel-body selector, I set the border color to match the one I specified in the selector above. If you don’t do this, you’ll still have the default border around the center. I also specify a light-yellow background color for the contents of the Panel.

Finally, for the .x-panel-header-text section, I change the appearance of the font from the default blue text to a white text in a different font.

Now you have a panel which can perfectly match any color scheme you need to support and it gives you a simple way to introduce ExtJS without it standing out from what you are already doing. For example, on my project, I’m going to use a pair of Ext.Panel widgets on the sidebar for navigation and a most-recently-used files list, which looks something like this:

In this example, the theme is still blue, but I changed the header gradient, the shade of blue for the lines, and applied a light-gray background.

Some Tips

Firebug or Webkit (Chrome/Safari) are your friends. Use the element inspectors to look at what classes are applied to the various ExtJS widgets. Theming ExtJS is all about overriding the existing styles.
Panels are about the easiest thing to style, and it gets harder from there. If you really want to get a custom theme, I suggest start by working with the x-theme-gray.css and then overriding from there. The gray theme will give you widgets that blend pretty easily with any theme, and then you can selectively add some bling to the elements you care about.
Remember that your overridden styles must come after the stylesheet link for ExtJS. For example, if your stylesheet with the overridden styles is called custom.css, ensure your header section contains this:

Revenge of the Browser

Tim — Sat, 12 Jun 2010 13:02:14 +0000

Last weekend I attended the awesome Texas Javascript conference down in Austin, TX. This was probably the best geek conference I’ve been too. It made the early Rails conference look downright corporate. TXJS had awesome parties sponsored by Google and Facebook, the top names in JavaScript for speakers, and an open bar with mimosas for breakfast. This sets the bar pretty high on the geek awesomeness scale.

One of the most interesting discussions at the conference revolved around server-side JavaScript. Some very clever programmers have taken the V8 JavaScript runtime from Chrome, wrapped it with a library and pushed it out as a runtime for executing JS scripts on the server. The project is called NodeJS and it already has a pretty rich plugin environment around it. The implication is you can actually write a high-performance server-side application in JavaScript.

The trend for the past several years has been for the server-side programming languages to hide the JavaScript from developers. Both Rails and GWT approach things with a “use our language to do it all”. There is obviously value in this approach for people who don’t know JavaScript, but NodeJS suddenly flips that model on its ear.

The NodeJS story is “you use JavaScript already in the browser, so why not use the same skills on the server”. We now have a programming paradigm established at the browser that is pushing in to the lower tiers, rather than the lower tiers pushing out to the web. NodeJS has potential to obsolete a lot of what we think of as server-side development. Both Yahoo and ExtJS have projects in the works that use NodeJS as the backend, and I bet Google must have something going too.

NodeJS is basically the new Ruby. Keep an eye on what the cool kids start doing with it, and give it a try yourself. We’ll be seeing a lot more of it in the future.

The Case for Strength

Tim — Sat, 22 May 2010 13:53:47 +0000

The pendulum has swung once again and I have escaped the world of architecture to get back to delivering software. I left Bank of America (Countrywide) for the second time last week, but not the mortgage industry. I am now the Application Manager for the origination system Nationstar Mortgage.

The challenge for my first week has been getting my head around the codebase. The application is a combination of a vendor solution along with a lot of custom code built up along the side. Like a lot of in house applications which started small, this one has grown in to what I call the “big ball of mud” pattern, where there was not the long term vision and architectural rigor for structuring a scalable, maintainable application. The fun part is it is my job to fix it.

After a week of looking at code, I have acquired new-found love for strong typing. In a mad genius, army-of-one development mode, the freedom of dynamic languages is both liberating and powerful. But as you start to add more cooks to the kitchen, things start to go downhill rapidly.

Case in point, I was attempted to troubleshoot a sporadic NullPointerException that pops-up in production. The culprit method is getting an object out of a list, and calling a method on a nested object it contains. I’m trying to determine if the object itself is null, or if the nested object is missing, so I’m tracing back how to where that object comes from.

The problem is that the instance of the object comes from an ArrayList, which is created from an object in HashMap, and neither makes use of generics. I know what my final object is supposed to be, but I have to trace back through other code to see how that the HashMap is being populated with.

This whole codebase has left me begging for generics. Generics in Java are not just about type safety, they are about documenting your code. For example, instead of:

ArrayList myLoans = new ArrayList();
HashMap properties = new HashMap();

You should make use of generics so that other people aren’t left guessing on the contents:

List<Loan> myLoans = new ArrayList<Loan>();
Map<String,Address> properties  = new HashMap<String,Address>();

In the second case, I know I have a list of Loan objects, and I know I have a map where the key is a String and the entry is an Address object. I don’t have to jump around in the code to see how they are used to understand exactly what they contain. Note another difference: I use the collection interfaces (List, Map) in my declaration rather than the implementation classes (ArrayList, HashMap).

From an object-oriented programming perspective, you should always strive to hide the implementation details of objects. And by using the interface, you buy yourself the flexibility of being able to swap out for a new implementation class without breaking the code. For example you could change the ArrayList to a Vector if you needed the synchronization and not break downstream code.

So with my dive back in to the bowels of enterprise software development, I’ve regained a new appreciation for my old friend Java. There is great strength in strong typing which permits you to build much more maintainable applications than the alternatives. Use that strength and make your team happy.

I’ll Buy That!

Tim — Tue, 16 Feb 2010 01:42:47 +0000

So it has been a few weeks since Apple announced the iPad. I was pretty excited when I saw it, but gave it some time to digest what everyone else was saying and also the implications. The iPad definitely has its detractors, with most somehow working a feminine hygiene joke into their rants. But in the end, I’ll happily be first in line to buy one. Why?

The game changing aspect of the iPad is Safari. There will be plenty of cutesy apps, but I would sooner chew my own arm off than work with Objective-C. It is a disgusting abomination of a language. But having Safari on the iPad means developing feature-rich RIAs in HTML 5, with fast JavaScript, that can be packaged to deploy so that they appear the same as other iPad/iPhone applications (Dock icons, etc…). Best yet, Apple is giving the finger to Adobe and Flash. The iPad is going to put a nail in the coffin of Flash and help advance web standards by leaps and bounds.

Yehuda Katz of the jQuery team summarized it best in this blog post. I completely agree with him. The iPad is a godsend for HTML and JavaScript developers and anyone who values open web standards should be doing back flips right now. A thin tablet device with a cutting edge browser and wireless networking is going to open up a world of vertical market possibilities for web developers. I was really impressed with what Graham Glass did with his iPhone web application for EDU 2.0, and can only imagine how an application like this could take advantage of the iPad.

Check out the Safari Developer Documentation on Apple’s site sometime to really understand the vast programming playground Apple is creating for us. I’m actually excited about web development for the iPad and am looking forward to getting mine to play with.

Rails Flashback

Tim — Tue, 26 Jan 2010 03:45:57 +0000

While poking around one of the Ruby on Rails sites, I stumbled upon the video of DHH’s keynote at RailsConf 2009. Rails 3 looks really cool, but DHH has definitely mellowed from the 2006 and 2007 RailsConfs I attended. Just watching the keynote brought back some good memories of the 2007 RailsConf.

RailsConf 2007 was held in Portland, Oregon, which is about the most awesome city I’ve been to for a conference. It has all the amenities of a big city, but still keeps a quirky small town feel. Between the conference, awesome micro-brews, and Powell Books, it was a really good time.

This was the RailsConf I went to with my Windows notebook while 99% of everyone there was running on a MacBook, so I played the leper. The speakers were great, and it was absolutely hilarious when one of the vendors had the Extra Action Marching Band show up at lunch the first day to perform. It pissed off the stodgy convention center management, but it was a sight to see. Check out James Duncan Davidson’s excellent photos if you want to see how fun a RailsConf could be.

I was thinking of going to RailsConf this year, but it is in Baltimore. I’ve never been a fan of east coast conferences, and I’m worried RailsConf is losing its fire. Just like JavaOne tapered off in to boredom, RailsConf on the east coast could be its jump the shark moment. But if they ever get around to having it in Portland again, I’ll be there.

Cool CBT

Tim — Mon, 25 Jan 2010 03:21:37 +0000

After enough time in technology, one tends to become pretty jaded about vendor claims. I’ve seen enough miracle solutions before, most them involving code generation to “eliminate the developer.” It has gotten to the point that if I even hear a vendor mention SOA, I whip out a can of Bear Mace and let them have it.

So it came as a great personal surprise when I actually saw a vendor demo for something both cool and practical. I sit on the .NET Center of Excellence for our oversized company, and part of the role is listening to vendors show off their latest and greatest. Our last demo was from a company called InnerWorkings and I had honestly never heard of them before the demo.

InnerWorkings has an incredibly awesome computer-based training (CBT) system for learning .NET. It goes beyond book reading and is heavily based around coding exercises which are even scored by the system. It has a Visual Studio plugin for working with the vast library of learning material and links to O’Reilly’s Safari Books for reference.

I had never seen a CBT product before this which I would actually considered to be effective. This looked good enough that I would almost be willing to invest my own dollars. If you need to bring a development team up to speed on .NET programming, or a specific area on the bleeding edge, I highly recommend taking a look at InnerWorkings.

(Ext.)Direct Miss

Tim — Sun, 17 May 2009 16:19:40 +0000

One of the biggest announcements from last month’s ExtJS Conference was the new Ext.Direct functionality in ExtJS 3.0. My criticism at the time was that there was a lot of smoke, but no fire. Almost every session mentioned it in some way or another, but they weren’t producing any enterprise-worthy server code showing how it is implemented.

Now, a month later, more details are starting to emerge, including implementations for various technologies. I sat down yesterday morning intending to take a look at the server side code in the Ext.Direct Pack; in particular the .NET and Java implementations. I was pretty disappointed with what I saw.

To understand my disappointment, you need to understand a bit of history around what Ext.Direct is attempting to do. Ext.Direct is going to be an RPC layer that exposes stub objects on the client JavaScript side that remotes the method calls to the server using JSON (or POST parameters). The protocol definition is designed to be technology-agnostic and easy to implement. In implementation, it would be the near-equivalent of DWR, except it would also run on PHP, C#, Ruby, etc…

Since I’m familiar with CORBA, RMI, SOAP and WCF, I approached Ext.Direct with a more critical eye. The biggest glaring hole in Ext.Direct is the parameter passing. Let’s take a look at a couple examples to demonstrate the problem. All the examples will assume a Java backend, and the service we’ll expose is the PersonService. I’ll work from the interface, since we don’t care about the implementation details:

public interface PersonService {
 
}

Easy

We’ll add a method to PersonService to demonstrate the simplest scenario:

public int getPersonCount();

The payload from Ext.Direct would look something like this:

{ "action":"PersonService",
   "method":"getPersonCount",
   "data":[],
   "type":"rpc",
   "tid":2}

This is the absolute easiest method to deal with. The operation takes no parameters, and the return value is a primitive. Ext.Direct can deal with this easily, but so could any AJAX library, so no secret sauce here.

Object

One of the key advantages to an RPC protocol is the ability to pass Objects. Well complicate things a bit by adding the following method to the PersonService:

public Person getPerson(int id);

For our example, we’ll assume the Person class looks like this. I’m not including setters/getters to try and keep it short:

public class Person {
  private int id;
  private String name;
  private int age;
  private Date birthDate;
}

In the method I added above, the JSON payload from Ext.Direct stays pretty simple:

{ "action":"PersonService",
   "method":"getPerson",
   "data":[1],
   "type":"rpc",
   "tid":2}

This should return the Person with the ID of 1, and depends on the server code to correctly serialize the Person object to JSON.

Harder

Now let’s make things painful. I’m going to include a method to add a Person.

public void addPerson(Person person);

This is where the wheels fly off of Ext.Direct. Since the protocol specifies the data element as an array, I’m not clear on how Ext.Direct would deal with this from the client side. Every example so far works with primitives as parameters, so I haven’t determined what it would do with a Person.

Ext.Direct would be much happier if I defined the addPerson method like this:

public void addPerson(int id, String name,int age, Date birthdate);

Then, the JSON payload would look like this:

{ "action":"PersonService",
   "method":"addPerson",
   "data":[1,"John Doe", 25, "Sun May 01 1985 00:00:00 GMT-0500 (Central Daylight Time)"],
   "type":"rpc",
   "tid":3}

Even in this “happy path” scenario for dealing with an object, your server-side implementation would need to be able to correctly deserialize the stringified javascript date object, which is not anything the current implementations handle.

The protocol specification states that the data element can also be a JSON object with named parameters, but it is not supported in the first implementation. This is going to be absolutely critical if Ext.Direct is going to evolve into a real RPC protocol. For example, using a JSON object for the data element in the above example would result in a JSON payload like this:

{ "action":"PersonService",
   "method":"addPerson",
   "data": {id: 1,
           name: "John Doe", 
           age: 25, 
           birthdate: "Sun May 01 1985 00:00:00 GMT-0500 (Central Daylight Time)"},
   "type":"rpc",
   "tid":3}

This would at least allow the server code a means to try and instantiate an instance of the Person object, as long as the server code is implemented in a language that allows for reflection of the Object.

My grief with Ext.Direct is that correctly implementing the server-side code to support the specification is a non-trivial endeavor. One big piece missing is the metadata. In other RPC mechanisms, there is strongly-typed metadata which can be used to create the stubs. For example, CORBA has IDL and SOAP has WSDL.

Ext.Direct is missing a metadata layer to facilitate the passing of Object values. It is going to be difficult to implement a complete server-side stack to handle the permutations that will arise. Developers will either need to dumb-down the exposed services to handle the limitations of Ext.Direct, or else they will end up doing a lot of custom work on top of the server side implementation to handle the type coercion.

I’m still not convinced Ext.Direct is the right path for ExtJS to be barking down. There are already established, tested protocols for handling RPC via JavaScript (DRW, WCF), and ExtJS already works quite well with basic AJAX over the HTTP protocol. Ext.Direct is adding a level of complexity to ExtJS which could easily turn into a rabbit hole that sucks up all their time. I would prefer they focus their precious development hours on the client library and leave the communication layers decisions to us. RPC is a complicated problem with a lot of history around it, and there is no reason for them to try and invent a new wheel in this space.

Flexible Spring

Tim — Sun, 10 May 2009 01:38:50 +0000

As I mentioned in my prior post, I’ve been going through the great Flex in a Week from Adobe. I finally hit Day 3 and had a need to play with BlazeDS for the second lesson. Being a fan of the Spring Framework, I decided to use the recently released Spring Blaze DS Integration 1.0rc1 (Spring-Flex). This ended up turning in to a bigger beatdown than I expected, for several reasons.

I really wanted to use the Spring-Flex integration because I like the annotation-driven dependency injection option that Spring brings to the table. Unfortunately, I could not find a single comprehensive document or example showing how to setup a project from end-to-end using Flex and Spring-Flex. I started with my Spring template project, adding in the BlazeDS dependencies and configuration. I then stripped out the stuff I didn’t care about for this example. Then I went digging through the various reference guides and blog posts trying to figure out the correct configuration I needed on both the Java and Flex side.

After about three days of hair pulling, the pieces finally started to fall in to place. Once I understood the configuration, it became a breeze to configure services to be exposed by Spring-Flex and to call those services from Flex via a RemoteObject. I’ve linked the complete Java project and Flex project archive below:

Spring-Flex Project

Flexbuilder Project Archive

There is a README.txt file in the root of the Java project directory that walks through the setup. This project is configured to talk to a MySQL database using an iBatis DAO layer and includes the setup scripts, all run from Ant. The build file also makes use of Ivy to grab dependencies, thus reducing the number of jars I have to include.

The Flex project is configured to talk to the exposed employeeService on localhost, so you’ll need to change the configuration of the RemoteObject if you want to point to a different destination.

Here are some of my lessons learned that will hopefully help others:

#1: Life is easier if you keep BlazeDS’s services-config.xml file in the default location: WEB-INF/flex/services-config.xml. The version of this file that comes with the BlazeDS turnkey download has a small problem. It does not specify default channels, which is what FlexBuilder will use to figure out what is going on. Look at the version I have in the Java file and notice at the top:

>
  >
     ref="my-amf" />
  >
>

You’ll want this in your services-config.xml file if you plan on specifying an application server in FlexBuilder.

#2: And on the subject of application servers, you actually don’t even need to specify the server technology. I built my solution as a standalone Flex project with a standalone Java project and had the two talking together without a problem.

The secret to making it work is in how you configure the RemoteObject in FlexBuilder. Here is the configuration for my RemoteObject:

 id="employeeRO" 
  destination="employeeService" 
  showBusyCursor="true"
  fault="handleFault(event)">
  >
    >
       id="amf" uri="http://localhost:8080/flex/messagebroker/amf"/>
    >
  >
   name="getEmployees" result="allEmployeesHandler(event)"/>
   name="doCreate" result="employeeHandler(event)"/>
   name="doUpdate" result="employeeHandler(event)"/>
   name="doDelete" result="employeeDeleteHandler(event)"/>
>

Specifying the ChannelSet enables you to take control of where the RemoteObject is binding to instead of relying of FlexBuilder magic. Just change the URI to point to the correct location.

There is one little catch. You need to set the FlexBuilder build output directory to Tomcat’s webapps/flex directory (after you have deployed the war file), or you’ll get a security exception about breaking out of the sandbox. I’m guessing that the flex file is looking for the services-config.xml file to figure out what it is supposed to do, and if it is not in the correct directory relative to the SWF file, your application will barf. So deploy the flex.war file from the Java project first, then play with the flex half of it.

#3: Once you have the dependencies sorted out, configuring the Flex broker is literally a one-line configuration option. Check out web/WEB-INF/flexDispatch-servlet.xml in the Java project and notice this line:

/>

That’s all you need. Really. This one line of config uses “sensible defaults” to initialize BlazeDS. It will read services-config.xml from the default location (see tip #1) and setup the endpoints for you based on the configuration.

#4: I’m a fan of annotation-driven configuration for Spring, and Spring-Flex does not disappoint. Here is the implementation of the EmployeeService class:

@Service("employeeService")
@RemotingDestination
public class EmployeeServiceImpl implements EmployeeService {
 
    @Autowired
    private EmployeeDao employeeDao;
 
    @RemotingInclude
    public List<Employee> getEmployees() {
        return employeeDao.getEmployees();
    }
 
    @RemotingInclude
    public Employee getEmployee(String id) {
        return employeeDao.getEmployee(id);
    }
 
    @RemotingInclude
    public List<Employee> getEmployeesByDepartment(String department) {
        return employeeDao.getEmployeesByDepartment(department);
    }
 
    @RemotingInclude
    public void doCreate(Employee employee) {
        employeeDao.createEmployee(employee);
    }
 
    @RemotingInclude
    public void doUpdate(Employee employee) {
        employeeDao.updateEmployee(employee);
    }
 
    @RemotingInclude
    public void doDelete(Employee employee) {
        employeeDao.deleteEmployee( employee.getId() );
    }
}

The top @RemotingDestination tells Spring-Flex this is a service that is going to be exposed via BlazeDS. You can provide an optional parameter specifying which channels to use, if you have several configured. Then, each method you want to expose is annotated with the @RemotingInclude annotation. Methods that should not be exposed can be annotated with the @RemotingExclude annotation.

So if you’re following along with Flex in a Week, or have just been trying to get Spring-Flex up and talking to a Flex application, give the demo a try and look over the source code. This corresponds to the second video of Flex in a Week, Day 3. I wish I would have known some of these things starting out, so hopefully I can save other people some time.

Flex in a Week

Tim — Tue, 05 May 2009 17:35:14 +0000

One of my unexpected take-aways from the ExtJS conference last month was that I need to start looking at Flex again. This isn’t necessarily for the Flex framework itself, but because of AIR. I’ve started to see a lot more AIR applications popping up, and my Twitter client (Twhirl) is even AIR based. ExtJS with AIR makes for an extremely powerful combination.

So to build a foundation for AIR, I decided to learn Flex. After a strong year of JavaScript, Flex starts to make a lot more sense from a syntax standpoint. And ironically, the best way I’ve found to learn Flex is free: Flex in a Week.

Adobe has produced a truly outstanding series of video training classes for Flex. Although it is structured as five days worth of materials, I’m only getting through half a course each day due to quiet time constraints with a two-year old in the house. I have been very impressed with the quality and level of detail. The videos aren’t full of fluff and get quickly to code. There are exercises interspersed with the training videos, but I’ve passed over them, opting instead to follow along with the videos.

The only downfall to my choice to follow the videos instead of the exercises is that Adobe didn’t make it easy to find some of the supporting pieces you need to follow the videos. For example, there is an XML data file called employees.xml used for a lot of the code in the videos that is nowhere to be found. Ultimately, I found a CSV version of the data file in an AIR Sample, along with the images used for building the employee directory application.

In the interest of helping out others who start on Flex in a Week, here are the supporting files necessary for following along with the code. I’ve only finished the second day, so I’ll try and add any additional parts I find missing.

employees.xml – the XML data file with the employee information (right-click to save it)
headshot images – the thumbnail images for the directory, both normal and small sized

I’m hoping to finish up the tutorial this week and jump into more complex things with Flex. I’ve been very impressed so far, although not enough to eat crow yet on my negativity towards Flash in general.

What about Flex books? I picked up Programming Flex 3: The Comprehensive Guide to Creating Rich Internet Applications with Adobe Flex and it has been a total disappointment. The book is very poorly structured and it jumps all over the place without a coherent plan. It swings between excessive detail of the Flash engine, followed by trivial, poorly explained examples of the Flex widgets. I may find value in it later as a reference, but am dumping it for now.

I did pick up another book that I really like a lot: Learning Flex 3: Getting up to Speed with Rich Internet Applications (Adobe Developer Library). This one is well structured and gets to the things I’m interested in, not the nitty-gritty details of the Flash player. I would recommend this one for anyone who is at a similar point in their Flex learning experience.

Beyond the Core

Tim — Thu, 09 Apr 2009 02:13:18 +0000

In my earlier post, I compared the new Ext Core JavaScript library with JQuery to demonstrate how close they are on core functionality. I explicitly kept the scope narrowed down to areas where the two libraries overlapped, and my conclusion was that both are winners but I prefer Ext Core since I use ExtJS and prefer the coding style.

In this post, I want to get in to demonstrating some of the features of Ext Core that are either coded differently from JQuery or that the base JQuery library does not implement. The excellent Ext.Core manual has more detail on all the functions, so I’ll just bring attention to some of cool functionality I like.

Base Class Enhancements

One feature that might be controversial for some developers is that Ext Core augments some of the base JavaScript objects to ensure some features are present across implementations and to add some useful helper methods. The JavaScript Augmentation section of the manual has details on all the enhanced methods. Function, Array and String are the three base objects that get augmented.

For example, the String object is augmented with a static format() method that essentially allows the String to function like a typical printf function:

var dest = 'World';
var greeting = 'Hello';
var msg = String.format('{0}, {1}!',greeting, dest);
// msg contains "Hello, World!"

The Array object is augmented with indexOf() and remove() methods, and the Function object itself picks up several OO-centric functions.

The reasoning behind the augmentations are in the manual. I have mixed feelings on augmenting the language’s base objects, but the features are appreciated.

Namespaces

Using a namespace mechanism so that all your variables don’t pollute the global namespace is something every JavaScript coder should be doing. There are plenty of code snippets out there to demonstrate how this is done, but Ext Core makes it easy for you by including namespace support as a part of the library. All this is handled through the Ext.namespace() static method.

Take a look at the sample below. The comments indicate the filenames:

// first.js
Ext.namespace('First');
First.name = 'Tim';
 
// second.js
Ext.namespace('Second');
Second.sayHello = function(name) {
    alert( String.format('Hello, {0}',name) );
};
 
// main.js
Ext.onReady(function() {
	Second.sayHello( First.name );
});

The three JavaScript files don’t even need to be imported in this order. Everything happens through the namespace references declared at the tops of the files and managed by Ext Core. In this case, objects called First and Second were created under window, and the sayHello method and ‘name’ variable were placed under them. This means our code only added two variables to the global space. This didn’t make a difference with only two variable declarations, but can have a huge impact with a typical application.

Namespaces can be hierarchical, so you can limit the global pollution to a single entry. For example, you can define a namespace like this:

Ext.namespace('Application.Init');

Ext Core will create all the intermediate namespaces, so you could places variables under both Application.Init and Application with this single declaration. This provides a similar naming hierarchy to what you would find in Java packages or C# namespaces.

Encode and Decode

Ext Core provides helper methods to encode and decode both JSON and URL-encoded data. The Ext.encode and Ext.decode will encode or decode JSON objects to and from Strings. This is useful for the AJAX methods, as I demonstrated in my other post. In the current beta, the encode and decode methods aren’t implemented yet, but they are in the documentation, so I’m expecting to see them before the final release.

The Ext.urlEncode and Ext.urlDecode methods will encode or decode JSON objects to URL-encoded strings. One typical example is to decode query string parameters. For example, if the page URL was this: http://mycoolapp.com?name=Tim&lang=Java, you could easily decode the query string into a JSON object using this snippet:

var params = Ext.decode( document.location.search.substr(1) );
alert( String.format('Hello, {0}', params.name) );

Yes, this is a bit of a hack. I didn’t do error checking to ensure there was a value for search before using substr(). The substr() is necessary when working with a query string because the search value will start with a question mark (?), which the Ext.urlDecode method won’t strip off.

Templates

Ext Core thankfully includes Templates, a feature generously carried down from ExtJS. Templates simplify the repetitive generation of HTML fragments, which is something that typically happens in AJAX intensive web application. The Ext.Template class allows you to define an HTML fragment as a template, using tokens which will be replaced with the values from a JSON object. For example, here is a code sample of a Template used to format an RSS feed from Slashdot that I turned into a JSON object:

// Feed.data is an array of JSON objects that look like this:
// {title: 'title', link: 'link', description: 'description'}
 
var template = new Ext.Template(
            '',
            '{title}
',
            '{description}',
            '
');
 
// stories is the id of the empty div on the page
var stories = Ext.get('stories');
 
Ext.each(Feed.data, function(item) {
    template.append(stories, item);
});

This snippet also demonstrates the Ext.each() helper method for iterating over the contents of an array. You can download the full snippet here to play with.

As Ext Core is still in beta, there is a disconnect between the API documentation and the actual implementation. If the Ext.Template class is updated to correspond to the documentation, there are also some neat formatting effects that can be applied. For example, instead of the placeholder {description}, you could use {description:ellipsis(20)} which will truncate any string longer than 20 characters and place ellipsis at the end of the string.

I’ve covered a few of the cool features to make your JavaScript code easier and more maintainable. Ext Core also has some neat OO functionality that I’ll cover in another post.