Category: JavaScript

ExtJS’s Grid Clipboard plugin is borked by design

I’ve been meaning to write this for nearly a year, but I held off hoping things would change with the next release. They didn’t, so I’m writing this: the Clipboard plugin for the Ext.grid.Panel class – which provides cut-and-paste support for the enhanced table widget – is borked by design. It does stupid things, and Sencha says it should do the stupid things. In this post I share what these things are, and how I’ve overriden the default behaviour to do something hopefully less stupid. Warning: this is a rant.

Continue reading “ExtJS’s Grid Clipboard plugin is borked by design”

Upgrading to ExtJS 6.2

Sencha recently announced the general availability of ExtJS 6.2. People who regularly read my posts (hi, to all three of you. 😉 will be aware that I’ve been working with the ExtJS library for a number of years now, while building a suite of apps of some not inconsiderable size1. It’s probably not the largest ExtJS app in the world, but it’s up there. And when you work on an application for a number of years, you’ll need to upgrade its framework from time to time.

Every time I’ve done this, the process has been a bit different. This time, it’s different in a good way – it was easy.

Continue reading “Upgrading to ExtJS 6.2”

So… NPM doesn’t care about intellectual property rights?

The NPM organisation, a for-profit company, has just demonstrated that it doesn’t care about the IP rights of contributors. As a organisation built entirely on the contributions of others, this is a worrying precedent.

Background

Azer Koçulu had developed and distributed, via NPM, a module called
left-pad. It’s a simple library, consisting of 11 lines of code, that does what it says on the box – pads a string by adding spaces to the left.

This module then got picked up and used by lots of other modules. Apparently it had been downloaded nearly 2,500,000 times in the last month.

Ko̤ulu had another module, called Kik. He received a cease-and-desist order from a lawyer complaining about trademark violation. He disputed that, and the lawyer then went to NPM. NPM decided to transfer the ownership of the Kik module Рnot remove it, but to assign ownership to a third-party.

Not surprisingly, Ko̤ulu was annoyed by this. So he yanked all of his modules Рabout 250 of them Рfrom NPM. Including left-pad.

This broke lots of things – heaps of projects around the world started to see failures due to the missing dependency on left-pad. In many cases, these were secondary dependencies – where ProjectA breaks because it depends on ProjectB, which depends on left-pad.

There is no question that this is a messy situation. But the fix that NPM decided on was worse. They un-unpublished the most recent version of left-pad, apparently at the request of a new owner.

What NPM should have done

It’s fine that someone can claim the left-pad module – if it’s been abandoned, it’s up for grabs. Nothing particularly wrong with that.

But the new owner only gets access to the name – they don’t suddenly get rights to the previously published code. Nor can NPM assign them the rights – by their own terms of service, they lose those rights when a module gets unpublished.

The new owner should have taken the couple of minutes it would have taken to fork the left-pad code base (which, under the WTFPL license used to distribute it, would have been perfectly fine), then packaged it up and submitted to NPM as a new module. They could even have re-used the version number, which would have solved everything.

In the case of Kik, NPM could have expelled the offending module. They could have claimed a safe-harbour provision and left it there. But they should not have assigned ownership to a third-party. And they really should not have double-downed on their transgression by doing it again.

Summary

NPM does not care about the IP rights of its contributors. They have shown they are willing to transfer IP to third-parties, and even to transfer IP they’ve explicitly had their rights to distribute removed.

I would suggest not publishing anything to NPM.

Logarithmic Axes for ExtJS Charts

ExtJS includes a number of nice charting options. I mean, it’s no HighCharts or D3, but it’s not bad. But – it can’t do a logarithmic axis.

A logarithmic axis is useful for displaying data with a large range of values. Sometimes these values are already on a log scale – e.g. the Richter scale is a log scale, as is decibels. You can plot this on a normal linear numeric axis. But sometimes your values can’t be easily converted to a log scale. Maybe you’re plotting wealth distribution. Or, in my case, particle size distributions, where the sizes can range from metres down to microns. When dealing with something like this, you need a log axis.

Continue reading “Logarithmic Axes for ExtJS Charts”

Fashionable ExtJS and Web Services

ExtJS 6 was released at the end of June, and one of the nicest new features in it is a change to their CSS tooling – they’ve replaced Compass with a JavaScript-based implementation of SASS called Fashion. One of the neatest features is “Live Update” – this takes the traditional ‘watch’ approach one step further, and instead of just rebuilding your CSS when you change a SCSS source file, it updates the CSS inside the running browser, without needing a page refresh! This is just awesome, and not something I’ve seen before in my (admittedly limited) experience with web development tools.

But there’s just one problem… you have to use the embedded web server started with the sencha app watch command. Which is fine if all you’ve got is a webpage, but if you’re dealing with web services (as so many web apps do), it’s a bit restricting – at least if you don’t want to configure your app or server to allow cross-site scripting.

But Live Update is too awesome to forego! What to do?

Continue reading “Fashionable ExtJS and Web Services”

Upgrading ExtJS – issues with templates

Quick _aide-mémoire_ so that I don’t forget. When upgrading from ExtJS 4 to ExtJS 5, if you’ve got any components that use a custom template, and expect `childEls` to be configured correctly, you need to add a `data-ref` to the generated HTML.

Quick aide-mémoire so that I don’t forget. When upgrading from ExtJS 4 to ExtJS 5, if you’ve got any components that use a custom template, and expect childEls to be configured correctly, you need to add a data-ref to the generated HTML.

Continue reading “Upgrading ExtJS – issues with templates”

ExtJS 5 and Gradle – Playing Together

Augmenting ExtJS with Gradle

ExtJS is pretty nice, overall, and it comes with a powerful build tool – Sencha Cmd.

Running builds with it can be tedious, because it doesn’t have any up-to-date checks – it constantly rebuilds stuff it doesn’t need. Oh, the time wasting!

As it turns out, Sencha Cmd is an Ant-based build tool. Which means we can create Gradle builds that augment it – given us support for such things as up-to-date checks.

Like this:

ant.importBuild 'build.xml'
def packages_dir = file('../packages')
clean {
doLast { delete 'bootstrap.js', 'bootstrap.css', 'bootstrap.json' }
}
refresh {
inputs.dir 'app'
inputs.file 'app.json'
packages_dir.listFiles().each() { package_dir -> inputs.dir new File(package_dir, 'src') }
outputs.file file('bootstrap.js')
outputs.file file('bootstrap.json')
}
js {
inputs.dir 'app'
packages_dir.listFiles().each() { package_dir -> inputs.dir new File(package_dir, 'src') }
outputs.file file("../build/${this.property('build.environment')}/${projectName}/app.js")
}
resources {
inputs.dir 'resources'
packages_dir.listFiles().each() { package_dir -> inputs.dir new File(package_dir, 'resources') }
outputs.file file("../build/${this.property('build.environment')}/${projectName}/resources")
}
sass {
inputs.dir 'sass'
packages_dir.listFiles().each() { package_dir -> inputs.dir new File(package_dir, 'sass') }
outputs.file file("../build/${this.property('build.environment')}/${projectName}/resources/${projectName}-all.css")
outputs.file file('bootstrap.css')
}
page {
// what are the inputs to page, I wonder?
// the outputs are the microloader.js and the index.html...
}
view raw build.gradle hosted with ❤ by GitHub
# the default Build Environment. Production is the default for Sencha Cmd.
# Use -Dbuild.environment on the command line to change, otherwise it doesn't get passed to the ant build properly
build.environment=production
# The project name. Should match what is in the app.json file
projectName=MyApp
view raw gradle.properties hosted with ❤ by GitHub

Share and Enjoy!

Lessons learnt from a bug

This is a rant about a bug report I raised with ExtJS a few weeks ago. That said, I’m using the bug more as a teachable moment than anything else; I’m certainly not trying to bag ExtJS (which I quite like, despite some of its quirks). But this bug does highlight a number of “things done wrong”, which I want to learn from so that I don’t commit the same errors.

(No knowledge of ExtJS is required, and whilst I will describe the details of the bug in depth, the technical issues involved aren’t meant to be the takeaway points)

Continue reading “Lessons learnt from a bug”

Giving the ‘hasOne’ association some love

One of the really nice features of ExtJS, to my mind anyway, is the rich model architecture, and how models can be associated with each other. However, the quality can be a bit erratic – certainly, it appears that the HasOne association (which allows a one-to-one relationship) could use some loving, as it isn’t as well developed as the more commonly-used HasMany

Continue reading “Giving the ‘hasOne’ association some love”

%d bloggers like this: