2010-08-22

Shockwave-Plugin mag ExtJS nicht

Oho, Firefox hängt sich auf, wenn auf Lino/DSBE Demo gehe.

Internet Explorer meldet “Expected identifier, string or number” in der site.js, offenbar weil für ihn default ein reserved keyword ist. Okay okay, nehm ich eben ‘std’ statt ‘default’. Aber nach dieser Änderung funktioniert dort alles.

Verursacher scheint der Shockwave Flash Plugin Version 10.1.82.76 zu sein. Der beißt sich scheinbar mit der ExtJS. Das passiert nicht nur mit Lino, sondern auch z.B. wenn ich auf http://www.sencha.com/products/js/ gehe und dort irgendeines der Beispiele starte.

Ich habe das Problem im ExtJS-Forum gemeldet.

  • Nachtrag 28.08.: hat nichts mit ExtJS zu tun, denn der Shockwave Flash Plugin Version 10.1.82.76 lässt meinen Firefox (v. 3.6.8 on Windows XP) jedesmal erfrieren, sobald er aktiviert wird.
  • Nachtrag 09.09.: Nachdem FF sich auf 3.6.9 aktualisiert hat, funktioniert wieder alles. Das incremental upgrade funktionierte übrigens nicht, aber der Updater entschied dann automatisch, ein komplettes Ugprade zu machen.

Release im ÖSHZ Eupen

In /admin/install habe ich die Anweisungen zur Installation von appy.pod hinzugefügt. Pisa werden wir ja bis auf Weiteres nicht benutzen, aber ich lass das noch in den Anweisungen stehen. Die Druckmethoden (print methods) müsste ich ja mal dokumentieren. Bisher habe ich an zwei Stellen angefangen: /admin/ConfigureNotesTemplates und /admin/printable.

Die Aussage “print method kann auch leer sein. Eine Notiz dieser Art kann dann eben nur am Bildschirm konsultiert werden und ist nicht druckbar.” stimmte noch nicht. Jetzt wohl. Dazu musste ich in den beiden Feldern NoteType.print_method und NoteType.template blank=True und null=True hinzufügen. Jetzt hätten wir mit dieser Änderung allerdings einen ersten Fall für South. Denn solange ich die Datenbank nicht angepasst habe, kriege ich IntegrityError: notes_notetype.print_method may not be NULL.

Also ran an den Speck und http://south.aeracode.org/docs/tutorial/part1.html lesen.

Zuerst auch ein Upgrade meiner Kopien von South und Django (revision 13467 to 13621).

Jetzt habe ich gleich ein Problemchen:

T:\hgwork\dsbe\dsbe\demo>python manage.py schemamigration notes --initial
Lino-DSBE 0.1.2+ <http://code.google.com/p/lino-dsbe/>
Lino 0.8.3+ <http://code.google.com/p/lino/>
Django 1.3 pre-alpha SVN-13621 <http://www.djangoproject.com>
Python 2.5.2 <http://www.python.org/>
ReportLab Toolkit 2.4 <http://www.reportlab.org/rl_toolkit.html>
PyYaml 3.08 <http://pyyaml.org/>
python-dateutil 1.4.1 <http://labix.org/python-dateutil>
xhtml2pdf 3.0.32 <http://www.xhtml2pdf.com>
Creating migrations directory at 't:\hgwork\lino\lino\modlib\notes\migrations'...
Creating __init__.py in 't:\hgwork\lino\lino\modlib\notes\migrations'...
 ! Cannot freeze field 'notes.note.date'
 ! Cannot freeze field 'contacts.person.it_knowledge'

 ! South cannot introspect some fields; this is probably because they are custom
 ! fields. If they worked in 0.6 or below, this is because we have removed the
 ! models parser (it often broke things).
 ! To fix this, read http://south.aeracode.org/wiki/MyFieldsDontWork

Also in meiner lino.modlib.fields:

from south.modelsinspector import add_introspection_rules
add_introspection_rules([], ["^lino\.modlib\.fields\.PercentageField"])
add_introspection_rules([], ["^lino\.modlib\.fields\.MyDateField"])
add_introspection_rules([], ["^lino\.modlib\.fields\.MonthField"])
add_introspection_rules([], ["^lino\.modlib\.fields\.QuantityField"])

Richtig, das war’s:

T:\hgwork\dsbe\dsbe\demo>python manage.py schemamigration notes --initial
Lino-DSBE 0.1.2+ <http://code.google.com/p/lino-dsbe/>
Lino 0.8.3+ <http://code.google.com/p/lino/>
Django 1.3 pre-alpha SVN-13621 <http://www.djangoproject.com>
Python 2.5.2 <http://www.python.org/>
ReportLab Toolkit 2.4 <http://www.reportlab.org/rl_toolkit.html>
PyYaml 3.08 <http://pyyaml.org/>
python-dateutil 1.4.1 <http://labix.org/python-dateutil>
xhtml2pdf 3.0.32 <http://www.xhtml2pdf.com>
 + Added model notes.NoteType
 + Added model notes.Note
Created 0001_initial.py. You can now apply this migration with: ./manage.py migrate notes

Dummerweise kriege ich jetzt:

T:\hgwork\dsbe\dsbe\demo>python manage.py migrate notes
Lino-DSBE 0.1.2+ <http://code.google.com/p/lino-dsbe/>
Lino 0.8.3+ <http://code.google.com/p/lino/>
Django 1.3 pre-alpha SVN-13621 <http://www.djangoproject.com>
Python 2.5.2 <http://www.python.org/>
ReportLab Toolkit 2.4 <http://www.reportlab.org/rl_toolkit.html>
PyYaml 3.08 <http://pyyaml.org/>
python-dateutil 1.4.1 <http://labix.org/python-dateutil>
xhtml2pdf 3.0.32 <http://www.xhtml2pdf.com>
Running migrations for notes:
 - Migrating forwards to 0002_auto__chg_field_notetype_template__chg_field_notetype_print_method.
 > notes:0001_initial
Traceback (most recent call last):
  ...
  File "l:\snapshots\django\django\db\backends\sqlite3\base.py", line 200, in execute
    return Database.Cursor.execute(self, query, params)
django.db.utils.DatabaseError: table "notes_notetype" already exists

Das ist logisch: er will die Migration 0000 anwenden, aber die hatten wir ja schon. Ich habe ja nicht von Anfang an Mit South gearbeitet. python manage.py migrate --list zeigt mir:

notes
 ( ) 0001_initial
 ( ) 0002_auto__chg_field_notetype_template__chg_field_notetype_print_method

02.10 Uhr : Ich hab meine Frage an south-users geschickt und geh jetzt erst mal schlafen.

9.00 Uhr : Das war mal wieder ein Fall von RTFM. Die Lösung ist migrate --fake : “Records the migration sequence as having been applied, but doesn’t actually run it.” Antwort auf meine eigene Frage nach south-users.

Also der Punkt “South aktivieren” kann aus der /todo raus.

Weitere Benutzbarkeits-Tests:

  • Wenn es in der Auswahlliste für NoteType.print_method eine RtfPrintMethod gibt, obschon sie nicht funktioniert, dann soll dort erst recht auch eine LatexPrintMethod stehen.
  • Im Feld Note.url fehlten die Optionen blank=True und null=True. Das ist Migration Nummer 0003.
  • Upps, wenn man vom Detail einer Person aus Notizen erstellen will, dann ist das noch nicht benutzerfreundlich genug. Neuer Punkt in der /todo.
  • Aber vor allem wird dort Note.person (der fk zum Master) nicht eingetragen. Das liegt an lino.ui.ext_ui.ExtUI.a2btn.

Die Arbeitsweise von lino.ui.ext_ui.ExtUI.a2btn() ist sowieso einige Gedanken wert. Hier der momentane Code:

def a2btn(self,a,**kw):
    if isinstance(a,actions.SubmitDetail):
        kw.update(panel_btn_handler=js_code('Lino.submit_detail'))
    elif isinstance(a,actions.SubmitInsert):
        kw.update(panel_btn_handler=js_code('Lino.submit_insert'))
    elif isinstance(a,actions.ShowDetailAction):
        js = "Lino.%s(panel,{record_id:ww.get_current_record().id});" % a
        js = "function(panel,btn) { %s }" % js
        kw.update(panel_btn_handler=js_code(js))
    else:
        kw.update(panel_btn_handler=js_code("Lino.%s" % a))
    kw.update(
      text=unicode(a.label),
    )
    return kw

Und Lino.build_buttons() verarbeitet die “actions” von a2btn ja dann zu echten Buttons:

Lino.build_buttons = function(panel,actions) {
  if (actions) {
    var buttons = Array(actions.length);
    for(var i=0;i<actions.length;i++) {
      buttons[i] = new Ext.Toolbar.Button(actions[i]);
      if (actions[i].panel_btn_handler)
        buttons[i].on('click',
          actions[i].panel_btn_handler.createCallback(panel,buttons[i]));
    }
    return buttons
  }
}
  • panel_btn_handler ist eine Funktion, die als Parameter sowohl das Panel als auch den Button kriegt.
  • Ein GET /api/contacts/Persons?fmt=insert gibt korrekterweise eine Insert-Form zurück, die auch im Prinzip funktioniert. Außer dass der Titel nicht richtig ist. Aber es fehlen die Default-Werte der Felder: Zumindest language muss einen Defaultwert kriegen.

Das Insert-Fenster hatte auch Navigations-Buttons und ein Quickfilter-Feld, was natürlich Quatsch ist.

Check-in zwischendurch im Rahmen des /releases/2010/0824 (und Install im ÖSHZ Eupen).