What Is ExtJS ExtJS 4+ Extensions Examples Tutorials

2Nov/160

Declarative Listeners vs. Control

Back in ExtJS 5 Sencha rolled out a rather cool concept of declarative listeners, where you could write something like this:

{
    xtype: 'button',
    handler: 'onButtonClick'
}

...note that onButtonClick is a string, rather than a function reference. The idea here is that the actual function would be resolved at runtime and will be located somewhere in the ViewController world. It was described well by Don Griffin in his blog post: https://www.sencha.com/blog/using-viewcontrollers-in-ext-js-5/.

However, what was omitted in this blog post and the guides, is the potentially powerful and risky "up the component tree" resolution of the ViewController. Read on to learn more with a Sencha Fiddle example...

VN:F [1.9.22_1171]
Rating: 10.0/10 (1 vote cast)
13Sep/160

Layout Run Error: Case of Hidden

It seems that I have started cataloging my experiences with the rather common Layout Run Error in ExtJS portals, as it's one of the most frustrating errors to fix. Previous editions include:

This time I came across another rather simple scenario where I was troubleshooting something unrelated and in process was setting "hidden: false" on various components, in hopes of divide-and-conquering my way out of the issue.

Sure enough, got a "Layout Run Error" when I set one of my components as hidden. There was nothing particularly special about it - a Container extension sitting inside of another Container with "auto" layout. At that point I commented out my Container instead of setting it hidden: no more layout run error!

I decided not to spend time figuring out why this particular container didn't like being hidden from the very beginning, especially considering this is in context of rather stale 4.2.1 ExtJS codebase. Nonetheless, the lesson is: even a simple act of having component declared as "hidden: true" initially can be enough to cause Layout Run Error.

VN:F [1.9.22_1171]
Rating: 10.0/10 (2 votes cast)
24Aug/160

ExtJS 6 DataBinding vs. Premium Licensing

I recently ran into some frustration as I was doing some refactoring and my databinding stopped working for some view. Turned out I misspelled "viewmodel" where it should've been "viewModel" and it didn't get declared for one of the views. As a result, a simple HTML bind like this stopped working:

xtype: 'component',
bind:'<div class="stacked-label-group">' +
        '<div class="label-title">{i18n:translate("appointment_info.appt_info.promise_time")}</div>' +
        '<div class="label-value">{promisedDateOrWaiter}</div>' +
     '</div>'

Turned out that I didn't have a "promisedDateOrWaiter" to bind to (since I didn't actually have a view model), which caused even the label data binding to fail to render (even though that one did exist at a different higher level). So the danger with these view models is that even if one of many fails in the binding, the whole binding fails (at least in case of html type of bindings).

Unfortunately this isn't easy to troubleshoot as there are no error messages in the console or exceptions to pause on.

However, Sencha does offer an Inspection tool: https://www.sencha.com/products/inspector/

I evaluated it and one of the features it offers is being able to catch faulty bindings like this one. The ironic part is that you need to purchase a "premium" license to get the tool, which is almost double the cost of the standard license just to get the framework. I really hope Sencha will write some tutorials on how to debug these data bindings effectively without the custom tool.

VN:F [1.9.22_1171]
Rating: 10.0/10 (1 vote cast)
19Aug/160

Layout Run Error: Case of Toolbar

Last year I wrote about the rather grim approach to troubleshooting ExtJS 4 (or 6 Classic) "Layout Run Error" issues:

Debugging ExtJS "Layout Run Error"

Now I came across a scenario now with a rather simple and unexpected fix. Consider this scenario where a panel specifies defaults for the "collapsible" behaviors of its child panels, but also has a toolbar as a child:

{
    title: 'Floating Footer',
    autoScroll: true,
    defaults: {
        xtype: 'panel',
        collapsible: true,
        collapsed: true,
        titleCollapse: true,
        margin: '0 30 0 30'
    },
    items: [{
        title: 'Panel 1',
        margin: '30 30 0 30',
        html: 'Panel content!'
    },{
        title: 'Panel 2',
        html: new Array(1000).join('Lorem ipsum '),
        collapsed: false
    },{
        title: 'Panel 3',
        html: 'Panel content!'
    },{
        xtype: 'toolbar',
        margin: '30 30 30 30',
        items: [{text: 'Back'}, '->', {text: 'Next'}]
    }]
}

A seemingly harmless configuration, this would throw "Layout Run Error" all day long with ExtJS 4.2. Why? Because apparently the "collapsible" configurations in the defaults somehow affect the toolbar (who while not a panel, but is a container). Easy fix - negate those configurations on the toolbar:

{
    xtype: 'toolbar',
    margin: '30 30 30 30',
    collapsible: false,
    collapsed: false,
    titleCollapse: false,
    items: [{text: 'Back'}, '->', {text: 'Next'}]
}
VN:F [1.9.22_1171]
Rating: 10.0/10 (2 votes cast)
13Dec/150

Hybrid Apps: Staged Rollouts

I love native apps, but for large enterprise projects they've been making less and less sense as mobile devices have become more powerful and the modern browser capabilities have exploded in the recent years.

One particularly important aspect of mission- critical mobile app is the risk involved with rolling out each new version. Imagine waiting out the 10 day approval period from Apple only to discover that you had a royal screw up and now the production version is unusable. Now you need a day or two to fix the issue, then another 10 days for approval, all while your app is unusable? A single occurrence can be enough to destroy your business.

Consider the advantages that a hybrid app can offer you in this case, illustrated in the following fictitious scenario, based on real life implementations I've been involved with:

  • The hybrid app stack is based on PhoneGap and Sencha ExtJS6
  • Has not needed an app store redeploy in years because the native code has no need to change
  • The app downloads its JavaScript code dynamically
  • Depending on the organizational unit that the user belongs to, or whatever organization they are choosing to operate in during their session, a different version of the JavaScript code is downloaded
  • A seamless transition between different versions of code occurs as the user navigates between different organizational units

This approach allows you to perform staged rollouts of new production code, or to perform AB testing on potential code candidates, within isolated organizational units, without risking mass disaster, with no regards for the app store or the 10 day waiting period. Try doing that with a native app.

Now some of you might be thinking "but it's against some policies to remote download code" and I say "welcome to the big league, boys". When we are talking about multi billion dollar enterprises, it costs peanuts to "persuade" Apple to "overlook" these policies and countless businesses operate based on this model.

VN:F [1.9.22_1171]
Rating: 9.0/10 (3 votes cast)
Page 1 of 1412345...10...Last »