Blog

Ext JS 4 Preview: Refactoring & Standardizing the Rendering Process

December 13, 2010 | Jamie Avins

Ext JS 4 Preview: Refactoring & Standardizing the Rendering Process by Jamie Avins Over the past 4 years, the Ext JS codebase has evolved; new components have been added and coding standards have improved. During this process, it was necessary to go back every so often to refactor older components and keep processes in sync.

Until Ext JS 4, there has been no standard way to render components. In the past, Panels rendered primarily by creating the elements they needed and adding them to the dom directly, picking up references along the way. Fields on the other hand, manipulated the autoEl DomHelper configuration and then wrapped specific html fragments as needed. Grids made extensive use of templates to build up their markup and inject it into the page.

For Ext JS 4, our goal is to unify these techniques into one cohesive standard by leveraging XTemplate and DomQuery. This standard is easy to work with and allows developers the flexibility required to develop robust components. This standard will be used internally across all of our components.

Introducing renderTpl, renderData, and renderSelector

All components in Ext JS 4 are rendered with a base div element which provides a unique id, and baseline component classes (cls, cmpCls, baseCls, and ui). If additional elements are needed to create a component, they are now handled with an XTemplate (renderTpl). Data for the XTemplate is read from a renderData object and Ext.Element references can be placed on the component instance via renderSelectors. The renderSelector is scoped from the base div element and uses standard css selectors. These Ext.Element references are part of the component lifecycle and removed automatically when the component is destroyed. The following example will help illustrate the creation of a custom component:

Simple custom icon component example:

 
IconComponent = Ext.extend(Ext.Component, {
   iconCls: 'myIcon',
   renderTpl: '<img alt="" src="{blank}" class="{iconCls}"/>',
   onRender: function() {
       Ext.applyIf(this.renderData, {
           blank: Ext.BLANK_IMAGE_URL,
           iconCls: this.iconCls
       });
       Ext.applyIf(this.renderSelectors, {
           iconEl: '.' + this.iconCls
       });
       IconComponent.superclass.onRender.call(this);
   },
   changeIconCls: function(newIconCls) {
       if (this.rendered) {
           this.iconEl.replaceClass(this.iconCls, newIconCls);
       }
       this.iconCls = newIconCls;
   }
});
 

The renderTpl defines an XTemplate with “blank” and “iconCls” variables which are read from renderData at render time. In addition, an “iconEl” reference to the Ext.Element is applied to the instance at render time. The changeIconCls method can now use the iconEl as soon as the component has been rendered.

There are 17 responses. Add yours.

Jay Garcia

1 year ago

Very excited about renderTpl!!  This is going to make creating custom components so much cleaner!

JF Cambot

1 year ago

Je m’éclate aujourd’hui avec la 3.3.X mais les dernières annonces d’ExtJS donnent vraiment envie d’être très vite en février !

Crysfel

1 year ago

This is great!! Standars make things easier smile

Daniel Jagszent

1 year ago

Looks like there’s a bug in the example code. Calling changeIconCls before rendering will set the iconCls property but not the renderData and renderSelectors properties. It’s probably better to set renderData and renderSelectors in onRender and not in initComponent (provided, that onRender will still be there in ExtJS 4)

Jamie Avins

1 year ago

Daniel, indeed. That will teach me to copy/paste examples too quickly.  I’ll update the sample to onRender as it should be.

devtig

1 year ago

Excellent. And will we use initComponent or constructor method in Ext Js 4? In 3.x initComponent doesn’t seem to have an advantage over the constructor method.

Jonathan

1 year ago

Waiting with excitement and anticipation until the release of 4.0.

ray_iceman

1 year ago

I wonder if this new version will include especial support for IE9. Also how easy will be to upgrade from Ext JS 2.0. Somebody does know?

gevik

1 year ago

This looks great for creating new components. I wonder what the impact would be for existing custom components which need to be migrated to 4.0

myext

1 year ago

Waiting the release of 4.0.

Radu Brehar

1 year ago

Very nice! This will truly allow very customized components. I am thinking of building panels using HTML5 features, so defining a very simple template with a minimum of dom elements, that uses rounded corners and all good stuff in HTML5, without the overhead of building a lot of dom. Excited about the release and looking forward to it!

Dmitriy Pashkevich

1 year ago

Great! Another automation of every-time routine! Also excited about renderSelectrors!

Jogos

1 year ago

I’m impressed with this software, I want to try the new Ext JS release as soon as possible. Very good work guys.

Dhana

1 year ago

Started learning ExtjS 1 month Great control over applications..! Expecting for ExtJS 4.0..! ..Is Ext-Designer has any new features.. or updates..?

Say

1 year ago

I’ve got a question about ExtJS 4.0. Does it have reasonable support for html escaping? Because with ExtJS 3.x I have XSS-headache (and No - escaping is not work for server, if you don’t understand this, you must be retarded or something). If you don’t have idea for it, maybe you should implement something like django autoescaping?

Tof

1 year ago

This is going to be legendary !

It looks like the sencha time has gone from 2 to 20 members during this year.

What

1 year ago

That crap code makes things easier?  But, that still looks like god-awful junk doesn’t it?  “class=”{iconCls}”>‘,” ... “iconEl: ‘.’ + this.iconCls” —really?  Why not just use Silverlight or Flex or Lazlo or JavaFX and build an RIA without the headaches?  They’re available now…

Comments are Gravatar enabled. Your email address will not be shown.

Commenting is not available in this channel entry.