Outside the Box() » extjs

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:

(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.

Ext Conference, Day 3

Tim — Thu, 16 Apr 2009 17:09:41 +0000

The third day of Ext Conference 2009 was only a half-day, which turned out to be a good thing given the trainwreck start. They were an inexcusable 20 minutes late in opening the door for what should have been 15 minutes of closing remarks. Instead, it turned into a 30+ minute demo of the new UI designer. Yes, the designer is awesome and will rock the ext world, but it is beyond me why they would improvise a demo on the morning of the last day. This should have been either on day one or possibly part of Jack’s keynote on day two.

With events now running 45 minutes late, the final two sessions ended up being pretty disorganized. I went to the “Mainframe to Web” presentation by Rich. I had just done a similar project and was interested in what he had to say. Turns out their showcase pretty much faked an integration with the backend by using a screen scraper on the server side which translated terminal session screens to ExtJS metadata. They didn’t change any of the backend code at all. I’ll give them credit for finding a clever solution, but I’m not convinced it is the best one. When we confronted a similar problem, we ended up wrapping backend functionality in AS/400 stored procedures we called from the middle-tier.

The positive side effect of the wheels-off schedule was that Rich rushed his presentation to try and wrap up on time. The other presentation, ExtJS deployment, was only halfway done, so I jumped in to catch the last half of it. In this case, it seemed like the heart of the presentation was in the last half, so I basically got the best of both presentations.

The deployment presentation covered a lot of the useful tools for bundling up your JavaScript. I had heard of JS Builder before, but plan on taking a deeper look now. It can create a single JavaScript file from many smaller files. YUI Compressor is the recommended tool for really putting the squeeze on your JavaScript files, but even then, Jamie still recommended ensuring you use GZip/Deflate on the web server for JavaScript files. He also talked about a tool for creating a multi-image sprite file of several small images that can also have a big impact. I came away with a lot of things to research and this should be a top presentation to check out when they put them online.

The final session for the day was Scott covering the Ext.Writer. This has got to be one of the coolest features of ExtJS 3.0 and they really should have moved this earlier rather than waiting for the last minute. The Writer addresses the problem of handling CRUD operations for Stores. It can use REST-like URLs like /app/update/1 or /app/delete/1 with the record ID as the final parameter. It pushes a JSON object back to the server containing the information that needs to be acted on. It even addresses passing a primary key back to the Store on a create operation. This is looking a whole lot cooler than Ext.Direct and I want to give it a try for my application.

I didn’t sit through the final Q&A session as I needed to bugout for the airport. Based on the tweets so far, it doesn’t look like much was discussed. Overall, the conference was excellent and I can chalk up the final day to growing pains. What will be interesting to see is what happens in the coming weeks. Ext.Direct was talked up in about every session, but there is an incredible lack of detail for how it will be implemented with mainstream enterprise technologies (Java/C#). Abe talked about the Marketplace, which sounds like the equivalent of RubyForge for ExtJS. If they can get it up, it will be cool. Finally, the UI Designer is what everyone really wants but it is slated for v3.1, and no one would talk timelines for it.

Ext Conference, Day 2

Tim — Thu, 16 Apr 2009 11:40:59 +0000

After the 100mph pace yesterday, day two of the conference settled in to a comfortable 55mph. The big news of the day was during the keynote, when they released RC1 of ExtJS 3.0. Jack was the scheduled keynote speaker, but I get the impression he doesn’t like speaking in front of large groups. His keynote lasted all of five minutes. He covered the history of ExtJS in two minutes and said ExtJS 3.0 is here. And that was it. Abe was left scrambling to fill a rather large hole in the schedule, and he called up Darrell of the GXT (Ext GWT) team to talk about their v2.0 release.

Darrell is a nice guy, but I was ready to pull my hair out listening to him. I had lunch with him yesterday and to say he is excited about GWT is a major understatement. In spite of being a Java guy, I don’t like the idea of writing my web UI in Java. It’s like the Hibernate mafia who think you can write a database application without knowing SQL. Each of the tiers has a best-in-breed language for addressing that tier’s problems. An enterprise developer better know SQL for talking to databases, Java/C# for the middle tier and HTML, CSS and JavaScript for the front end.

After the keynote, we had another smoothie break. The smoothies were good, but the general consensus would have preferred coffee in the morning and smoothies in the afternoon.

Aaron kicked off the regular sessions with a breakdown of the signature demo in ExtJS 3.0 — Image Organizer. This is the meatiest demo so far, and was interesting to see how they structured the code and where they subclassed. The application uses Ext.Direct, but the backend was only PHP. One of the first questions Aaron got asked was when they would release other backends. He really danced around the question without giving a true answer, saying that maybe there would be something released in the next week or so. Ext.Direct is starting to sound like a lot of vaporware. They talk a good game of how it will be able to use annotations/attributes server side for exporting objects and other cool stuff, but no one is producing any code. Ext.Direct is the new Duke Nukem Forever.

The next session I attended was one of the funniest. Glen Liptka talked about user experience design with ExtJS. He is at Marketo, which has done the most incredible theming of ExtJS I have ever seen. He started the talk covering general usability and then demonstrated their application. The point he made that stuck with me is that your UI should have low WTF/min. Everyone got a kick out of that.

Next up was JC Bize talking about theming ExtJS. JC is the author of the Slate theme, one of the most popular third-party themes used in ExtJS. He is now an employee of Ext, LLC, so hopefully we’ll see some more cool themes in the pipeline. He showed off a couple cool themes and then got in to a basic example of how to change the theme of a panel. When playing with themes, Firebug is your friend. Unfortunately, he got sidetracked trying to answer an audience question and the presentation fizzled out.

I couldn’t catch the last session, as I had to make a phone call, but came back for the day-ending Ask the Ext Team. Nothing major came up. I tried to ask the question of why they didn’t use Sizzle for Ext Core, but my question didn’t get voted up and they ended the session before they got to it.

The day wrapped up with a social down by the pool with a cash bar. I really started to hate the Ritz after paying $8 for a beer. They definitely need to move the conference to someplace that understands Happy Hour. I managed to corner Aaron at the social and got my Sizzle question answered. He said they didn’t use Sizzle because it was too big and too slow. He did say the DOJO guys were working on a very cool new engine called Acme that looks promising. DOJO makes me nauseous just looking at it, so I won’t be investigating it.

The day ended for me again at the bar. I had dinner with another attendee who works at the DIA. Since I have a similar background, we had a lot to talk about. $35 for two margaritas and a plate of chicken quesadillas — ouch!

Day three is only a half day, but there are still two sessions I’m interested in, so it should be fruitful.

Ext Conference, Day 1

Tim — Wed, 15 Apr 2009 01:08:32 +0000

The first day of the first-ever Ext Conference wrapped up today. The day actually started last night when I got to the hotel. Jay Garcia and Shea Frederick both got in at about the same time as me. We had an impromptu meet-up at the hotel bar, where we hooked up with a few more conference attendees who were drawn to the geek conversation like moths to a flame.

One of the guys (Jerry), mentioned that Abe (Elias) was still in the big conference room preparing for the keynote. Since it was 12:30am, and tipsy geeks don’t have anything better to do, we paid him a visit. He was extremely cool, and ended up giving us the tour. He took us down to one of the other meeting rooms where a Rick, Aaron, Evan, Tommy and Chris were getting ready for their presentations too. After about a half-hour of the geekfest with them, I went to bed to be ready for the early start today. As a footnote to the evening, be sure to ask Jay how sissy drinks at the Ritz went over with him.

The conference started up at 8:30am this morning. Abe introduced the Ext development team, which was a lot larger than I expected – over a dozen people. He kept the introductions short so that we could get to Douglas Crockford, our keynote speaker. As he is a legend in the JavaScript community, it was exciting to see him talk in person. He covered a little bit of the history of JavaScript, then dived in to the future, including ECMAScript 5 (ES5). ES5 is going to be pretty impressive, but it will be years before we can really count on it being on all the desktops (thanks, Microsoft).

Most all the sessions throughout the day were at a good technical level. No fluff, just stuff. Aaron presented the new features of ExtJS 3.0, which drew almost everyone. They had to move the session back to the keynote ballroom. ExtJS 3.0 is super cool, with one exception, which I’ll discuss below.

Evan was up next, talking about Ext.data. Since there wasn’t a lot new in this space, this was more a rehash of the Ext.data classes. Evan definitely knows his stuff, and had some educational examples.

Chris then talked about Ext.direct. This is the one area of ExtJS 3.0 that I’m still skeptical on. One of the key parts of Ext.direct is the server-side component, yet everyone so far has been light on details for this piece. Chris is a Merb guy, so it didn’t help when he was showing Ruby code trying to explain it. Even listening to Jack discuss it in the hall left me feeling there were still a lot of smoke and mirrors around Ext.direct. In theory, Ext.direct should provide a server-technology agnostic RPC mechanism for talking to objects. I’m not convinced we actually needed this, and since I haven’t seen any real code behind it, I’m not sure what kind of state it is in. Hopefully, when Jack announces the release of ExtJS 3.0 tomorrow morning, I’ll get a chance to look at some code.

My final session for the day was watching Tommy discuss Ext Core. I’ve already covered Ext Core in some prior posts, but still managed to learn some things. Ext Core is going to really shake some things up when folks start to get familiar with it. I plan on wrapping up a post on the cool OO features of Ext Core this weekend.

That was it for the structured presentations. Here are a few other random thoughts and observations on the day:

Swag so far has been an Ext spiral notepad, a pen and a nice travel mug. There will probably be a riot if T-shirts don’t appear.
The next fool who gets up and asks about testing ExtJS websites with selenium is going to receive my travel mug upside their head. Asking the same question five times is not going to get you a different answer.
The meal was excellent. The hotel is nice, but a bit too ostentatious. It’s the Ritz, so you have to expect it, but it would have been more fun to have the conference in a more festive environment. Hint for Abe: Vegas, Baby!
Overheard a Salesforce architect talking about them moving to ExtJS. That would really rock if they did it.
The average age of the Ext dev team appears to be about 17 . They have a lot of bright, young talent on their hands. It will be fun to watch what they do with it.
Someone actually asked, in the group Q&A, if there were any books on ExtJS. Paying over a thousand dollars for a conference and not doing your homework is just plain dumb. Never ask something in front of a large group that 15 seconds on Google or Amazon could answer for you.
All the sessions were taped and Abe said they would be put up on the Ext site. Presentations should show up too.

I’m hoping tomorrow rocks too. We went non-stop from 8:30am to 6:30pm today, and it was a lot of fun. If they can keep up the momentum, this will turn out to be one of the best technology conferences I have ever attended.

Feedback

Tim — Sun, 05 Apr 2009 21:19:29 +0000

It has been fun watching the comments on my write-up yesterday about Ext Core on some of the sites it got posted to. It is clear, for some people, discussing JavaScript libraries has drifted into the same hazard zone as discussing religion and politics. While I appreciate all the feedback, and probably should have signed up for adwords before posting, I do want to clarify a few things:

GPL – I hate it, deal with it. There are two reasons a library author would use GPL. First, to prevent someone else from monetizing their effort (ala ExtJS), or second, because open source is an agenda and not a license. An altruistic developer who is interested in helping other developers without expectations of a return will use a reuse-friendly open source license for their libraries like Apache or MIT. If you’re trying to change the world, please, go ahead and use GPL. If you just want to help out your fellow developers, use something with no strings attached.
ExtJS Haters – still a surprising number of geeks out there who are bitter about the change from LGPL to GPL. I was a vocal critic of the change too. I got over it — I bought a license and no longer care. Best $289 I’ve ever spent. If you’re looking for a free ride, look elsewhere. Ext LLC is for-profit entity and I agree with them. People should be able to put food on the table writing cool code, and I won’t deny the talented developers at Ext LLC that right.
Fluff – I especially got a kick out of this. It was the longest blog post I have ever written (1800+ words) and tried to touch on as many areas as I could. I plan on following up with some more detailed posts. Guess you can’t make everyone happy.
The Conclusion – JQuery is an awesome library. I’ve used it for years. I’ve also used ExtJS and will now use Ext Core more. Why? For the same reason some developers gravitate to Perl and others to Java — Style. I come from a OO Java background, and thus the coding style of the whole ExtJS/Ext Core duo is more in line with my preferred comfort zone. Both JQuery and Ext Core are awesome libraries. Pick the one that suits your personal style and objectives.

New Kid on the Block

Tim — Sat, 04 Apr 2009 22:02:08 +0000

On this cloudy Dallas Saturday morning, the ExtJS team announced the availability of Ext Core (beta). Ext Core is the core DOM selection, manipulation and events library of ExtJS which has been extracted out into a separate library released under a more liberal license. They smartly released this under the very permissive MIT license, in contrast to the cancerous GPL used for the full ExtJS.

What makes this interesting is it positions Ext Core as a direct competitor to the popular JQuery library. I really like both ExtJS and JQuery, so I decided to run a quick comparison of the two libraries to see if Ext Core is up to the task of replacing JQuery in my developer toolbox. Since there is so much overlap between the two, it makes no sense to use both.

Round 1 – Size

Library size of the two is pretty close. The minified version of JQuery runs about 56K, while the minified version of Ext Core weighs in at 75K. The 19K difference might matter for an iPhone application, but even then, I would consider it negligible. Both are pretty small libraries, so we’ll call Round 1 a tie and move on to feature comparison.

Round 2 – Load Event

How each of these libraries works the document ready event is more a matter of style. The JQuery convention is to use the dollar sign ($) for for operations, although you can fall back to using the full name (jQuery). Setting up a ready event in JQuery looks like this:

$(document).ready(function() {
    // do cool stuff
});

Ext Core uses the static Ext class for the same functionality. Like the jQuery object, the Ext object is the heart of Ext Core. Setting up the ready listener in Ext Core looks like this:

Ext.onReady(function() {
    // do cool stuff
});

One big difference is the onReady method can take an additional parameter specifying the scope in which the onReady method should execute. This is not a big deal in most cases, but shows Ext Core’s attention to support object oriented JavaScript. Since I’ve never actually needed to specify the scope, I’ll call this round a tie too.

Round 3 – Selectors

This is the heart of both libraries, and a full comparison could fill a dozen pages. The short story is they both support basically the same set of CSS3 selectors along with some custom enhancements. From looking at the documentation, I couldn’t find any typical use cases that either couldn’t handle. Like the document ready example above, it just comes down to a matter of convention. For example, here is the code from each to add a class to a set of nodes:

// JQuery
$('td.age').addClass('someclass');
 
// Ext Core
Ext.select('td.age').addClass('someclass');

One major style difference between the two is that Ext Core has a tighter focus in handing elements with ids, since that is critical to the full ExtJS library. For example, Ext Core has the get() method to directly grab an element by ID, along with a memory-friendly fly() method. The fly() method does not create a new element wrapper in memory, and instead reuses a single global element object. This can save a lot of memory when you just need to do quick manipulations of single objects.

// Add a class to the element with ID of 'header'
Ext.fly('header').addClass('someclass');

For the memory saving fly operation, I’ll give the advantage to Ext Core, although they are essentially equal in their DOM selection abilities.

Round 4 – Events

Like the selectors above, there are basically style differences between the two libraries in how they handle basic event use cases. JQuery adds some methods to the jQuery object for registering common events. For example, here is the code to add a click event to a button for each, including the JQuery shortcut:

// JQuery with bind()
$('#myButton').bind('click', function() { alert('Clicked');});
// JQuery with shortcut
$('#myButton').click(function() { alert('Clicked');});
// Ext Core
Ext.fly('myButton').on('click', function() { alert('Clicked');};

JQuery brings some some additional enhancements to the game in the form of “live” events. This provides a way of attaching an event to all current, and future, instances of the selector. JQuery also supports event namespaces, where events can be fired in a hierarchy. Both are powerful concepts, but I’ve never had to use either.

The secret sauce for Ext Core is in extended configuration. With Ext Core events, you can also configure the scope (a common Ext Core theme), along with configuring the event propagation, extra parameters, and a delay. Here is a sample of a click event configured with ‘this’ scoped to the onClick event itself, to only fire once (single), with a delay of 100ms and an additional parameter (forumId) to be passed to the event handler:

el.on('click', this.onClick, this, {
    single: true,
    delay: 100,
    forumId: 4
});

So again, I’m going to call this round a tie. Both libraries handle simple event binding very easily. If you need the live events, the nod goes to JQuery. If you need the extra configuration options, Ext Core is your best bet.

Round 5 – DOM Manipulation

Once again, the two libraries provide a near complete overlap of basic DOM manipulation functionality. Each can easily create, move, add and insert DOM elements.

JQuery aims for convenience. For example, one feature of JQuery I really appreciate are simple methods to clear the content of a DOM element and set the text. For example, given:

First Message

With JQuery, it is simple to update the text:

$('#message').text('New Message');

The text() method removes all the child nodes of the matching elements and appends a text node containing the specified text. The text() method without a parameter will retrieve the text for a matching element. For Ext Core, you have to drop down to the DOM to set the new text value:

Ext.fly('secret').dom.innerHTML = 'New Message';

The Ext.Element class does not provide simple methods for setting the text or removing all the children of an element, which I find to be an annoying inconsistency.

On the plus side, Ext Core provides a lot more methods for manipulating the DOM. One of the cool ones is the radioClass() method. This method will add a class or classes to an element and remove that same class (or classes) from all the siblings. For example, here is a simple table with a row having the ’selected’ class:

Name	Age
Bill	20
Alice	21
Jeff	22
Susan	23

This one line of Ext Core code will remove the ’selected’ class from the current TR element and add it to the first row in the table:

Ext.select('table tr:first').radioClass('selected');

So for this round, I’ll give the advantage to JQuery for the more consistent API, especially around manipulating the text nodes of an element. This is something pretty simple for Ext Core to address, which they really should. Ext Core does, however, offer more powerful DOM manipulation options.

Round 6 – Effects

I’m not a big effects junkie, so I won’t have a lot to say about this. Both Ext Core and JQuery provide a very similar set of effects for elements (hide/show, fade, slideIn/Out, etc…). Ext Core provide a more powerful API for creating custom effects, while JQuery addresses this with its rather extensive set of plug-ins. I’m calling this one a tie.

Round 7 – AJAX

Ext Core and JQuery both make AJAX simple, but again, we’ll see that JQuery adds more simplified methods while Ext Core offers more powerful configuration. Here is a sample of an AJAX call that returns JSON data:

// URL returns a JSON object like this: {name: 'Tim'}
 
// JQuery 
$.getJSON('http://myurl', function(data) {alert(data.name);});
// Ext Core
Ext.AJAX.request({
    url: 'http://myurl', 
    success: function(response) {
        var data = Ext.decode(response.responseText);
        alert(data.name);
    }
});

JQuery provides the simplified getJSON() method where the parameter to the callback has already been decoded into a JSON object. For Ext Core, the callback receives the XHR response object and you have to decode the text to JSON.

The Ext Core request() method demonstrates a typical ExtJS convention of using a JavaScript configuration object as a parameter instead of using multiple parameters.

Both libraries provide strong AJAX support, so we’ll go with a tie for this round too.

Round 8 – Documentation

There is no contest in the documentation department. While the JQuery documentation has improved, the Ext Core documentation blows it away. From the excellent manual to the high-quality API documentation, Ext Core sets the standard for what all documentation should look like.

Round 9 – Intangibles

For JQuery, the biggest intangibles are its plugins and support from Microsoft. JQuery is intentionally designed to provide a simple core set of functionality and to be easy to extend. There are hundreds of plugins people have written for JQuery in the Plugin Repository. As with all things open source, some are very good and some are kinda crappy, but you can be pretty certain to find a plugin that covers about anything you might be trying to do that is not covered by the core JQuery API.

Microsoft support is also a biggie. They have decided to include JQuery as a base JavaScript library in their web tools going forward. This means you won’t need to get special blessings to use JQuery in large corporate environments — it will be part of the core Microsoft bundle, with support and all.

Ext Core, being brand new, is lacking in both community and support. Ext LLC, the company behind ExtJS and Ext Core is a small software shop trying to get by in a tough economy. While their products are cutting edge, I’m expecting them to be bought out by a larger company before too long. I keep trying to talk my Spring Source contacts into buying them, but I have a feeling they’ll be bought by Adobe.

So from an intangibles perspective, JQuery is the winner. It is guaranteed to have longer legs under it, at least until we see where Ext LLC ends up.

Conclusion

Both Ext Core and JQuery are solid, complete base JavaScript libraries. JQuery leans towards simplicity while Ext Core offers enhanced configuration. The choice of which to use will come down to where you are now.

If you use JQuery, and don’t anticipate using ExtJS, stay where you are. You’ve got a winner.
If you use ExtJS and have used JQuery as a light weight option for when you didn’t need the widget library, Ext Core is now your library of choice.
If you are in search of a JavaScript library, the choice is tougher. Unless there is a particular JQuery plugin you want to use, I recommend going with Ext Core. It starts laying the groundwork for using ExtJS, which you’ll want to do as you get in to building RIAs.
If you’re a corporate Microsoft shop, you probably don’t have a choice. JQuery is now something you can slip by the infosec police without making waves.

Ext Core is definitely a winner. In the past, I have used JQuery for projects that need simple DOM manipulation and ExtJS for when I need the widgets, layouts, etc… Now that I have Ext Core, I don’t see using JQuery anymore for the simple cases. I can standardize on using the same API paradigm between Ext Core and ExtJS.

Follow-up #1: Beyond the Core
Follow-up #2: Slick Speed

Springing Around with ExtJS

Tim — Sun, 01 Feb 2009 03:40:37 +0000

While playing around more with ExtJS and Spring, I ran in to one of my favorite annoyances — setting up a new project. I can create a new webapp in IDEA (or Eclipse) and add some dependencies, but it is still pretty empty. Maven can go a bit farther, but I don’t like how it handles transitive dependencies. None of these will really give me a good starting point out of the box without either copying a bunch of stuff over from other projects or writing a lot from scratch.

To finally scratch that itch, and move further along the Spring & ExtJS path, I turned my demo project into a basic template. The zip archive that you can grab at the bottom is a fully-configured Spring web application, including Tiles, Spring Security, Spring MVC, custom JSON view, Transactions and a Datasource.

To get started, grab the file, extract it to some directory. Open a shell, navigate to the Template directory and run the ant command ant dist. This will compile the whole project and create a Template.war file in the dist directory. Note, I use Java 6 for all development, so if you’re not at least at Java 5, you won’t be able to use this.

Before you drop the war file into Tomcat’s webapp directory, you’ll need to setup the database. First, copy the jar files in lib/tomcat into Tomcat’s lib directory. This is the MySQL JDBC driver and the JTA files for transactions. You’ll then need to create a new database on your local MySQL instance called tomcat. For simplicity in development, create a user with all rights to the tomcat database. Here’s the code to run from a MySQL shell:

create database tomcat; use tomcat; grant all on tomcat.* to tomcat@localhost identified by 'apache';
Your other option is to just put in your MySQL root username and password. To do that, or change the connection string completely, edit context.xml under web/META-INF. If you don’t use MySQL, you will have to edit this file and also put the correct driver in Tomcat’s lib directory.

Once you have the database setup, drop the Template.war file into your Tomcat webapps directory and startup Tomcat. Assuming Tomcat is configured to listen on port 8080, you can open the sample by browsing to http://localhost:8080/Template

The application only has a couple pages. First, the login page:

Spring Security is configured to route unauthenticated requests through this page for login. You can take a look at the applicationContext-security.xml file in WEB-INF to see how this was done. There are two users configured for now. User scott with a password of tiger and user bob with a password of password. Yes, not very clever, but it works. Scott is in both the ROLE_ADMIN and ROLE_USER roles, while Bob is only in ROLE_USER.

If you login with scott, you’ll be taken to the index page, which looks like this:

The index page simply contains a text box with a button. Entering a message and pressing the button results in an Ajax call to the server which echos the message back to the page. An HTML element in the middle of the page is updated with the result via JavaScript.

You’ll notice in the footer of the page you can see the currently logged in user on the left, and a link to log out on the right. Clicking the log out link takes you to the logout page, which looks like this:

Again, nothing fancy. Just a message saying you have logged out and a link to login again. Use the login link to login as bob and try the echo functionality again. This time you get a different result:

This demonstrates what happens with Spring Security via annotations. Here’s the echo method in the service layer:

As you can see, the method is secured with an annotation indicating the user must be in the ROLE_ADMIN role to use the method. Bob is only in the ROLE_USER role, so the call to this service fails.

The application makes use of a ResourceBundleMessageSource for the pages mapped through the htmlDispatch servlet. The login.jsp and logout.jsp don’t go through the dispatch servlet, so they can’t use the message bundle for the window and page title.

There is way too much to this simple application to cover completely now, but I’ll give the highlights of what to go look at in the major configuration files. Paths are relative to the project root:

web/WEB-INF/web.xml - notice that I configure two dispatch servlets. One catching *.htm and one *.json. This sets things up to treat Ajax requests differently. Spring Security is also configured here.
web/WEB-INF/applicationContext.xml – typical application context for a Spring application. I turn on annotation handling with package scanning under the sample.core package. Apache Tiles is configured in this file, and I have also configured a Transaction Manager around the JDBC DataSource. You should tweak this based on your underlying persistence preferences. I’m a RowMapper fan, but you can plug in Hibernate or JPA.
web/WEB-INF/htmlDispatch-servlet.xml - the context for web (*.htm) requests. This sets up the ResourceBundle for messages and a typical ViewResolver mapping the *.htm requests to jsp files under web/WEB-INF/jsp. Also configures component scanning for the sample.web package.
web/WEB-INF/jsonDispatch-servlet.xml – the context for Ajax (*.json) requests. Configures component scanning for the sample.json package and specifies a custom Ajax ViewResolver. This will automagically serialize all ModelMaps returned out of the Controller responded to *.json requests to JSON.
web/WEB-INF/applicationContext-security.xml – so simple to look at, yet so painful to figure out. This is the Spring Security configuration file. Although it looks deceptively simple, it was a beating to figure it all out. It enables annotation-driven security, which you saw on the EchoService above. It also sets up the form login and locks down all the pages. Note I leave the /resource directory open. This is where I put all my javascript, stylesheets and images. If you want to secure those resources, you’ll need to get more specific on the intercept-urls.
Users are declared at the bottom. Passwords are clear text, which is fine for a trivial demo, but you would want to replace this with something more industrial-strength in a real application.
web/WEB-INF/tiles-config.xml – the Apache Tiles configuration. I only setup one definition here to keep it simple.
web/WEB-INF/jsp/layouts/baseLayout.jsp – the base layout used for tiles. I’m only inserting content at two locations in the template. In the HTML head section, I allow for an optional insert of headerContent. I use this to include JavaScripts specific to a page. The other content is within the center div called mainContent.
Note that the body is pretty empty and that the divs all have the x-hidden class. This means they are not normally visible. I use an ExtJS Viewport for layout, which uses the contents of these divs.
web/resources/javascripts/layout.js – this JavaScript file was included in the baseLayout.jsp above. It creates the Viewport using a border layout.
web/resources/javascripts/index.js – the JavaScript file included for the index.jsp page. It decorates the plain HTML inputs on the page to do the cool Ajax stuff. Note towards the bottom how I use ExtJS to set focus on a form field and to bind the ENTER key to the submit button.
web/resources/javascripts/login.js – the JavaScript file use for the login.jsp page. If you look at login.jsp, you’ll notice there is no form. Everything is created by ExtJS from the login.js file, including the cool box effect. One trick is that Spring Security wants a normal form POST for the login form. I override the form to do a standard submit instead of an Ajax submit and set the form action explicitly.

This covers the major features. I’ll be using this as a base for other projects and will be expanding out my ExtJS demo. Since there are pretty much zero examples out there of tying together this stack, I hope this can be of use to some folks.

Project Template

2/28/2009 – upgrade to ExtJS 2.2.1, fixed compile issue on Linux, added in iBatis for ORM
3/26/2009 – I’ve setup a dev server with the latest version of the template at CodeZombie.com so you can check it out without having to install. User scott/tiger for credentials. I’ll be updating this install with a more feature-rich demo application shortly
3/28/2009 – changed around the project structure and build.xml to use Ivy for dependency management. Check the README.txt file in the root directory for the details.
4/28/2009 – updated the included JSON encoder to be able to return JSON arrays by using the key _root in the model map. If this key is found, its content will be used as the root element of the return JSON instead of encoding the whole map. Also removed the unicode characters from StringScrubber to make the compiler on Linux happy.

p.s. this pulls together a lot of jars and pieces from different folks to build the demo. If you use this for more than playing around, you need to make sure you respect whatever licenses the authors have in place.

Silver(very)light

Tim — Thu, 08 Jan 2009 14:21:31 +0000

My friend Caleb Jenkins of Improving Enteprises spoke at the North Dallas .NET Users Group last night about Silverlight 2.0 databindings, styles and templates. Caleb is a fun, energetic speaker, the kind of guy you want to have on your team or have a beer with. He’s definitely gungho over Silverlight, but I’m still not getting very warm to it.

Part of my grief with Silverlight is the same I have with Flex. We don’t need browser plugins to build feature-rich RIAs. I will concede the vector graphics space to these two technologies, but that is a space I could care less about. All the applications I work on involve web-based CRUD of business data. HTML and JavaScript are just fine at doing those, and I actually think ExtJS still does a better job than either with the widgets on the page. And since ExtJS is simple JavaScript, CSS and HTML, it will work with all browsers, including the iPhone, today.

To set the record straight, I’m going to expand my .NET demo project into a full demo site so you can see what I’m talking about. I’ll publish the URL when I’ve pushed some code.

I toss out my congratulations to Caleb on his diet. He’s lost 16lbs in only three weeks and it has motivated him to blog about it. He’s even going to have a contest to give away an MSDN subscription tied to weight-loss, although I think he should just give it to me for mentioning him in my blog

Also, I haven’t mentioned Improving Enterprises before, but I should. They merit a blog post of their own, but for now I can simply say they are the best small technology consulting company in the DFW area. I do not know of any other organization with such a concentration of A-list talent and would highly recommend them to any organization that actually needs to get something done.

The Missing Linq

Tim — Thu, 23 Oct 2008 03:26:28 +0000

I’ve almost wrapped up porting my ExtJS demo application to ASP.NET. It has been pretty simple so far once I realized I was trying to make it too complex. After getting a handle on ASP.NET MVC, I realized I didn’t need to use WCF for the JSON calls. ASP.NET MVC is pretty slick and has excellent built-in support for returning JSON data via the JsonResult class and Json method.

For the data, I’m using a very simple database I called Demo which contains two tables, City and Country. They look like this:

I’m using Linq to SQL for data access, and everything was moving along quite nicely until I ran into a small problem. In the Java version of my demo application, I used server-side sorting for the grid. How this works is that when you click a column header on the ExtJS Grid, the data store makes an AJAX call to the server controller with the POST data containing two parameters. The sort parameter contains the name of the column in the data store that the sort should be based on. The dir parameter has either the world ASC or DESC, indicating the direction of the sort.

The method signature in my controller which catches this request looks like this:

ASP.NET MVC will automatically map the two POST parameters to the two parameters in the method, since they have the same names. Where I hit a wall though was with Linq.

One of the big design features of Linq is to provide a strongly typed interface for the query language. Since I wanted the orderby statement to be based on the POST parameter, I thought I could do something like this:

Noticing no red squiggles, I assumed this would work. But it doesn’t. The problem is Linq is strongly typed, so it won’t accept a string after orderby. Linq wants something like this:

This would be cool in normal circumstances, but since I need to vary the orderby based on the sort parameter, I would have to do a large if-then block with multiple Linq queries, executing the required one based on the incoming parameter. Since that sounded like a pretty stupid idea, I dug a big deeper.

After much searching, I determined that Linq, as implemented, can’t handle the dynamic queries. But fortunately some other very smart people created a work around in the form of an extension to Linq called the Dynamic Query Library. Scott’s article provides a pretty good introduction. All you need to do is include the Dynamic.cs file in the solution and add the namespace to the imports.

Using the Dynamic Query extension methods, I can now do something like this:

The Dynamic.cs adds a new version of the OrderBy method which takes a string parameter containing the name of the field to sort on and an optional sort parameter. No if-then loops from hell and no more hair pulling trying to find the simplest solution that works.

I would bet the Dynamic.cs stuff ends up in core Linq, as it is simply too valuable for situations requiring dynamic data access, like my ExtJS demo. It also provides similar support for strings to the other Linq commands.

Now that I’ve gotten past the ugliness, I’ll be able to wrap up my ExtJS demo application. I’m adding some additional features to it which demonstrate some of the coolness of ASP.NET MVC, so stay tuned.