20120127 ======== Window management ----------------- Mir ist über Nacht klargeworden, dass im :lino:`neuen Windowing-System ` noch ein Denkfehler war: Nachtrag "window_history" zur :lino:`/releases/1.3.6`: `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 :func:`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 :func:`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" - :class:`lino.modlib.jobs.models.JobProvider` sind keine "Employer" ("Arbeitgeber"). Also "Arbeitgeber" --> "Stellenanbieter"