20120127

Window management

Mir ist über Nacht klargeworden, dass im neuen Windowing-System noch ein Denkfehler war: Nachtrag “window_history” zur https://www.lino-framework.org/releases/1.3.6.html:

Lino.current_window holds the current window.

Lino.window_history is a stack (an Array) of windows that have been hidden but are still “active”. Each item is an object with two attributes window and status.

Lino.open_window(win,status) : pushes the current window and its status to the stack, then shows the new window and activates the given status.

Lino.close_window(update_status) : closes the current window, pops the last window from stack and restores it’s saved status. If update_status is given, this means “update the stored status of previous window with some new values”. This is used after a SubmitInsert.

Complicated names

We had a case where lino.modlib.contacts.utils.name2kw() failed to correctly split a name into first_name and last_name. name2kw now supports a comma to handle complicated cases.

Noch Bugs im windows management

  • Lino.fk_renderer (Anklickbare Werte in einer Grid) funktionierte nicht.

  • Das mit dem update_status nach einem SubmitInsert musste ich noch verfeinern. Wenn man z.B. im Detail einer Person Nr. 123 in NotesByPerson doppelklickte und eine Notiz Nr 14 erstellte, suchte er nach dem Speichern des Fensters eine Person Nr. 14.

VirtualFields in Grid Views

I discovered that by mistake all VirtualFields were considered wildcard data elements. New testcase lino.apps.pcsw.tests.pcsw_tests.test07() to avoid this infuture releases.

py2xml() on iterables

Wow! Beim Optimieren der Ausgabe von [html] war mir aufgefallen, dass xmlgen es bisher erforderte, dass die ganze Tabelle in eine DOM geladen wird, bevor sie gerendert werden kann. Und das habe ich nun (wahrscheinlich) elegant gelöst, indem man als value eine Generator-Funktion angibt.

Man bedenke, dass der [html]-Button bewusst eine Tabelle mit allen Zeilen generiert, weil es ja eben eine druckbare Seite sein soll, ohne Navigator-Buttons, die der Browser je nach Druckeinstellungen selber paginieren soll.

Tests auf Jana mit einer Liste von 7825 Personen. Der Request http://jana/api/pcsw/Persons?fmt=printer dauert ca. 5 Minuten.

Vor dieser Änderung ging dem Server die Luft aus (memory exhausted), als ich die gleiche Seite ein zweites Mal anforderte.

Nach dieser Änderung ging ihm immerhin nicht mehr die Luft aus. Hier der Output von Top nach zweimaligem Request

 PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
2016 root      18   0 10716 3888 2020 S  0.0  0.2   0:00.17 apache2
2023 www-data  25   0  436m 283m 4076 S  0.0 18.5   5:34.01 apache2
2029 www-data  25   0  428m 276m 4068 S  0.0 18.0   5:06.28 apache2
2030 www-data  15   0 12228 5812 2332 S  0.0  0.4   0:29.16 apache2

Es gibt zwei Prozesse, die einkommende Requests abwechselnd beantworten

Nach viermaligem Request hat sichdie Situation stabilisiert:

 PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
3211 www-data  25   0  470m 318m 4072 S  0.0 20.7  10:43.11 apache2
3212 www-data  25   0  462m 310m 4068 S  0.0 20.2  10:15.31 apache2

Dennoch: bis auf weiteres setze ich mal eine Obergrenze von 300 Zeilen. Wenn die überschritten wird, kommt eine letzte Zeile “List truncated after 300 rows”. Mal sehen, wann das jemandem auffällt.

Übersetzungen

  • “Primary Clients” –> “Komplette Akten” statt “Komplette Klienten”

  • lino.modlib.jobs.models.JobProvider sind keine “Employer” (“Arbeitgeber”). Also “Arbeitgeber” –> “Stellenanbieter”