Month: August 2016

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: 4.9/10 (23 votes cast)

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: 4.7/10 (21 votes cast)