20120116

Ich war am Wochenende nochmal wieder ziemlich aktiv: der “Report-Generator” wird langsam fertig. Es gibt jetzt neben dem [csv]-Button einen [html]-Button, das Äquivalent der [Sh-F7]-Taste in TIM. Es kommt dort jetzt auch schon eine HTML-Ansicht der Grid raus, die allerdings noch nicht gestylt ist und auch noch nicht die geplanten (Zwischen)summen hat. Mein Plan ist, dass man in diesem Fenster dann mit Ctrl-P ohne viel Hantier einen “schönen” Ausdruck der Tabelle bekommt.

Auch gibt es jetzt die Möglichkeit, interaktive Parameter einer Tabelle anzugeben. Tabellen, die Parameter definiert haben, haben vor dem [csv]-Button einen [filter]-Button. Das ist ein Togglebutton, der das “Parameter-Panel” anzeigt/versteckt. Die erste Tabelle mit solchen Parametern (die neue Tabelle ContractsByUser) funktioniert schon ganz gut.

Bald kriegt z.B. auch die Tabelle “Personen” ein solches Parameterfenster, das dann teilweise die bisherigen Personensuchen ersetzt. Also die Felder, die momentan dort stehen, kommen in die Tabelle Personen als Parameter rein und können dann in allen Personenlisten benutzt werden. Personensuchen bleiben trotzdem bestehen für die Suche nach (un)erwünschten Sprachkenntnissen und Eigenschaften. Das sind Slave-Tabellen und die kann das ParameterPanel nicht (zumindest bis auf weiteres).

Und dann werden die beiden bisherigen “Listings” durch solche parametrierbaren Tabellen ersetzt:

  • “Datenkontrollliste” verschwindet in dieser Form, wird ersetzt entweder durch eine Serie von parametrierbaren Tabellen oder durch neue Filteroptionen wie “nur Personen mit ungültiger NR-Nummer” oder “nur überschneidende Verträge”.
  • “Übersicht Art.60§7-Konventionen” : das kann er momentan noch nicht

Es gibt auch noch ein Problem mit dem Layout des Parameter-Panels: Hintergrund ist weiß statt blau). Scheinbar das Gleiche Problem wie im Detail einer Notiz.

Internal design decisions

Another 5 hours of internal work on the report generator. Not yet worth to think in English…

summary_row kriegt jetzt den TableRequest (Parameter rr) nicht mehr. contacts.Person und ProjectRelated nutzten das theoretisch aus. Die Idee war, dass summary_row z.B. den Namen der Person eines Termins nur anzeigt, wenn rr.master_key nicht ‘person’ ist. Also wenn es sich um eine Liste von Terminen einer bekannten Person handelt, sollten nur die anderen Infos, aber nicht der Personenname angezeigt werden. Dieses Feature kam aber bisher in der Praxis nicht vor und war sowieso recht wackelig implementiert.

Das Problem damit war, dass ich TableRequest.__iter__ rausgeholt habe und summary_row dennoch sowohl für Listen als auch für Querysets funktionieren sollte.

Dann fiel mir auf, dass die ComputedColumn Quatsch sind. Stattdessen sollte ich machen, dass man virtuelle Felder auf auf einer Tabelle definieren kann. Summen will ich ja auch für normalen Felder haben. Gedacht, getan. Aber die Idee mit dem decorator @computed war gut, die übernehme ich zum Definieren von virtuellen Feldern: @virtualfield und @displayfield.

OverviewClientsByUser ist konvertiert, das scheint zu funktionieren. Bis auf die Tatsache, dass ContractsByUser in der ersten Kolonne statt des Benutzernamens dessen Nummer zeigt. Und ich muss noch eine neue Feldart “RequestField” machen.

Checkin erst am nächsten Morgen.