20100125¶
Bei den Änderungen, um die Kolonnen und/oder Editoren des ColumnModel als eigene Variablen zu deklarieren, stellt sich raus, dass der Trick mit der FieldElement.ext_options(), die um die eigentliche Component noch mal einen Container mit layout=’form’ packt, jetzt stört. Denn der editor einer Ext.grid.Column muss natürlich nur der Component ohne Verpackung sein. Puh!
Also: Der künstliche Container mit layout=’form’ wird jetzt nicht mehr in FieldElement.ext_options() erzeugt, sondern in field2elem(), die aus dem UI ins dessen main_panel_class() verlagert wurde. Neue Klassen MainPanel und WrappingMainPanel(MainPanel).
Ich glaube, die erweiterte ComboBox funktioniert jetzt. Ich habe in setValue() den Test, ob der Store geladen werden muss, erweitert, denn wenn er zwar geladen ist aber für einen anderen queryContext, dann muss er ja neu geladen werden. Ich kann einfach auf this.lastQuery testen, weil setQueryContext() den löscht. Aber das setQueryContext() ist noch nicht an die richtigen Events angebunden. Im GridMainPanel funktioniert es, aber im Detail ist sie momentan überhaupt nicht angebunden. Ich weiß auch noch nicht, ob die Slave Grids ihre ComboBoxen richtig einbinden.
20100126¶
Also Anbinden der ComboBox.setQueryContext() auch in DetailMainPanels. Anderthalb Stunden Aufräum-Arbeiten in extjs.py, um diesen Schachzug vorzubereiten.
Variable.has_comp kann weg.
Variable.js_lines() ist ein Iterator, der zeilenweise JavaScript-Code überreicht. js_lines umbenannt nach js_declare, weil es die Deklaration der Variable generiert.
Hinzu kommt js_run().
Variable.subvars() (die bisherige Variable.js_elements()) ist auch ein Iterator, der aber keinen JS-Code überreicht, sondern eine Liste von Variablen, die von dieser Variablen gebraucht werden. Präfix js_ sollte reserviert sein für JS-Generatoren. Ausnahme ist noch js_code, für die ich mit einen besseren Namen ausdenken muss.
Neue Methode MainPanel.job_constructor() enthält den Code, der vorher in ExtUI.view_report() und ExtUI.view_form() definiert war.
Diese Aufräumarbeiten haben übrigens auch schon mit Issue 90 zu tun.
So, es funktioniert: auch die ComboBoxen in DetailMainPanel kriegen jetzt ein setQueryContext() gemacht, wenn der selected_record in der Grid ändert. Außer dass mein Test in der ComboBox-Erweiterung (ob wegen geändertem queryContext neu geladen werden muss) offenbar noch nicht funktioniert: wenn ich nur blättere und sich das Land des Kontakts ändert, dann sehe ich zwar jetzt die drei Aufrufe von setQueryContext(), aber statt des Städtenamens steht nur die Nummer da. Erst wenn ich triggere, steht die richtige Städteliste da, und beim Zurückblättern kennt er jetzt die Städte aus diesem Land.
In der Tat, mein Test via !Ext.isDefined(this.lastQuery) bzw. this.lastQuery === null scheint noch nicht ganz das Wahre zu sein. Aber das lass ich jetzt mal offen, es gibt Dringenderes zu tun.
En passant habe ich das Interface für ContextAwareChoices noch verändert: Lino sucht die Methode get_XXX_choices() (wobei XXX der Name eines Feldes ist) jetzt nicht mehr im Report, sondern im Model. Habe ein bisschen gezögert, weil Django damit vielleicht in Zukunft mal Probleme hätte. Aber Vorteil ist, dass das jetzt noch ein bisschen eleganter ist, weil ich keinen Parameter recipient mehr brauche. Und der abstrakte Report Contacts, der nur zu diesem Zweck existierte, kann jetzt auch wieder weg.
Neue Seite LinoFeatures, und jetzt wird es langsam Zeit, dass ich igen mal wieder ans Laufen bringe für den Fall, dass sich am Freitag jemand für Lino interessiert.