20140729 (Tuesday, 29 July 2014)

A nasty JavaScript bug

I discovered and am investigating a bug in linoweb.js. docs/tickets/119. It happens when adding a new record to a grid using cell editing (which currently requires the user to press F2). The bug is not very urgent since the current production sites don’t really use this entry method. Most people even don’t know it. But it is necessary in an accounting application. It is a show stopper for Lino Così. I want to fix this bug. But it is a nasty one.

As usual when I must do some job which I don’t love, I find distractions. For example Ly watched one of my private blog pages and complained that you cannot start to page through all photos after having clicked on a first one. I concluded that she is right: atelier/sphinxconf/sigal_image now uses lightbox.

Hackerzacker, ich bin jetzt schon den dritten Tag mit diesem doofen Bug im JS dran! Da scheint etwas mit der inheritence (Ext.extend) nicht zu klappen.

Da stellt sich natürlich die Frage, ob ich nicht besser langsam mal auf die neueste ExtJS-Version umsteige. Erfreulich: ExtJS Version 5 ist raus! Weniger erfreulich: nirgends auf der Webseite finde ich einen Link für den Download der GPL-Version. Auch ein öffentliches Repository haben die ja nie gehabt. Okay, hier gibt es immerhin noch die Version 3.4.1.1. Mit der scheint Lino übrigens auch nicht zu funktionieren. Er meldet dann “TypeError: this.indexOf is not a function” in der JS-Konsole.

Das Upgrade zur Version 5 wird irgendwann kommen. Aber das wird ein Stück Drecksarbeit, auf die ich wenig Lust habe und für die es keinen zwingenden Grund gibt. Lino braucht eben Version 3.3.1. Insgesamt kein Problem wenn man es weiß.

Until now I believed that Sencha are glad about Lino selecting ExtJS as primary user interface (or at least that they would be glad if they would know it). But I start to wonder whether that’s true. They don’t give the impression that they care for the free users’ community of their products. And I am not the first to feel like this (probably rather the last…): a Premium user dnorman wrote in 2012 in a thread about (Public ExtJS github repository!):

Having harped on this issue with various persons at various times, it is becoming increasingly clear, despite some overtures to the contrary, that Sencha is not interested in this kind of community interaction.

This is a shame, because Sencha is by their very nature a tool-maker, and is pretty good at it too… but they absolutely cannot be in the trenches on a day-to-day-basis as a tool-user. This is evidenced by my rather large library of patches required to make ExtJS work for my application at all. (complexities for which dataIndex is unsatisfactory, the ability to render more than one instance of an MVC view/controller pair, etc, etc, etc) My company would be happy to surrender the copyrights for these patches, but there’s no mechanism to contribute them upstream. Yes, there’s the “feature request” process, but that’s not a good fit for the “this bit needs some re-architecting” scenario.

From my perspective, Sencha is rightly concerned with thought-leadership. This is a good thing in many ways. But without a significantly improved mechanism for user contribution and feedback, Sencha dwells in the echo-chamber, and runs the risk of having companies like mine abandon the platform.

In 2010 there is a blog entry announcing that Ext JS is Migrating to Git, and their GitHub account still exists, butI could not find anything helpful there.

Upgraded from Bootstrap 2 to 3

The above considerations caused some motivation to reactivate my search for alternatives for the ExtJS user interface. After looking at Angular.js & friends I fell back to our good old Bootstrap.

Until now Bootstrap (v2) was integrated into Lino as lino.modlib.plain. This app is now deprecated and replaced by lino.modlib.bootstrap3. Applications should not need to do anything because this was one of the “automatic” apps.

One good side effect is that the usage of the name “plain” to designate “an HTML interface using Bootstrap” is now history.

Existing functionality is converted to Bootstrap 3. But besides the look and feel there is no further visible change yet. There is still much to do before lino.modlib.bootstrap3 becomes a usable alternative to lino.modlib.extjs.

Checkin.

There is one degradation: in Bootstrap 2 it was possible to render three menu levels (e.g. Konfigurierung ‣ Kontakte ‣ Rechtsformen) using dropdowns with sub-dropdowns. This is no longer supported in Bootstrap 3 (see Bootstrap 3 dropdown sub menu missing).

Yes, listening to Mark Otto’s statement is probably more future-proof than trying to work around it. And in fact this would return us to how TIM did it: use several 2-dimensional menus instead of one 3-dimensional menu. TIM differentiates “main menu”, the “reports menu”, the “configuration menu” and the “explorer menu”.

One question is: should Lino analyze the menu tree and do this differentiation automatically (transparently, depending on the user interface)?