With ExtJS5 beta announced last week there were clear efforts on behalf of ExtJS 5 to behave closer to Sencha Touch in regards to utilizing the unique and powerful config system. Last year I wrote ExtJS vs. Touch Config System article to highlight some important differences. Today I’d like to explore this topic in the context of different versions of ExtJS 4 and ExtJS 5 beta.
I think this has been a hot topic lately: making web sites that adjust based on resolution of the device the user is using to browse. Now I’m not going to make this post about Sencha Touch. Even though in my “perfect responsive strategy” I would be using both ExtJS and Sencha Touch (and I can write more about that if you care to comment about your interest), this post is going to be only about ExtJS.
In this example we’ll be achieving the very common “navigation collapses to menu” effect, demonstrated here in my Android 4.x LG Intuition, by rotating the device from horizontal to vertical:
I’ve enjoyed the 4.2 ExtJS release since it came out; especially the new theme and grids. I recently wanted to “puff in” a Panel for some eyecandy, but I quickly realized it’s a bit trickier than you might think.
Components don’t have slideOut or fadeIn methods like Elements do.
It’s not a problem in case of “hiding” actions (i.e. slideOut or puff), which you can accomplish by something like component.getEl().slideOut().
However, in the case where you want to “show” a hidden panel (i.e. slideIn), in a case of deferred rendering (i.e. when creating and showing a new panel on the fly), the getEl() doesn’t have a DOM element to show yet, until the panel has been rendered.
The fadeIn method is achieved by showing a panel with CSS opacity 0% and then animating it back to 100%.
I ended up solving this via means of a plugin. Can you think of a more elegant solution?
Continue reading ExtJS 4.2 Plugin Example
ExtJS 4+ data stores allow you to sort data rather easily through either a “sorters” configuration on the store itself, or through the store “sort” method. Only one problem: all sorting is case-sensitive. Here’s a quick example of how you can customize the sorter to be case-insensitive, in a context of a combo box:
{ xtype: 'combo', fieldLabel: 'Supervisor', name: 'manager', queryMode: 'remote', store: Ext.create('Ext.data.Store', { fields: ['displayName', 'distinguishedName'], proxy: Ext.create('T4E.proxy.MSAjaxProxy', { url: '/User/SearchManager', reader: { type: 'json' } }), // eo proxy sorters: [{ property: 'displayName' , transform: function(val) { return val.toLowerCase(); } }] // eo sorters }), // eo store displayField: 'displayName', valueField: 'distinguishedName', forceSelection: true, typeAhead: true, minChars: 1 } |
See Previous Example First!
Takeaway from this post: Sencha SDK Tools 1.2.3 are still beta and I don’t advise using them in production. This is a follow up post to my previous examples – I spent some time the other day trying to set up a 1-click build process for ExtJS, and failed!
Custom Build File Size
First, let’s talk about the incorrect file size shown on this screenshot in my previous 2 posts:
In the “Custom Build” example, the custom-built app-all.js is shown as being 120KB in size. In reality, the file is about 400KB in size on the disk. I don’t understand why that is – compression? If that was the case, wouldn’t the 1MB ext-all.js in the “Full Framework” example be something closer to 200KB? After some Googling I couldn’t figure out how to tell if a file was compressed. Any advice here is welcome as I’m a bit lost.