================================
20140729 (Tuesday, 29 July 2014)
================================
A nasty Javascript bug
======================
I discovered and am investigating a bug in :xfile:`linoweb.js`.
:srcref:`docs/tickets/119`.
It happens when adding a new record to a grid using cell editing (which
currently requires the user to press :kbd:`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 :ref:`cosi`. 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:
:mod:`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
:mod:`lino.modlib.plain`. This app is now deprecated and replaced by
:mod:`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 :mod:`lino.modlib.bootstrap3` becomes a usable
alternative to :mod:`lino.modlib.extjs`.
Checkin.
There is one degradation: in Bootstrap 2 it was possible to render
three menu levels (e.g. :menuselection:`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)?