20100721

22.45 Uhr. Diese Woche werde ich nicht viel Zeit für Lino haben, aber hier zwischendurch ein paar Gedanken.

Also beim Implementieren von Previous/Next-Buttons im Detail-Fenster gibt es noch was zu Meditieren. Ich stehe vor der Entscheidung, ob ich im URI für einzelne Records eines Reports (1) den Primary Key oder (2) den Offset nehmen soll (also das “123” in einem URI contacts/Persons/123). Momentan ist es der PK. Aber zum Blättern wäre der Offset effizienter implementierbar. Zumindest fürchte ich, dass der Algorithmus von vergangenem Freitag in Reports mit vielen Zeilen nicht tragbar ist.

Andererseits müsste ich bei Adressierung per Offset zunächst ein Mittel finden um zu verhindern, dass der Benutzer nach einem Submit in einem Detail-Fenster plötzlich einen ganz anderen Record angezeigt bekommt (weil inzwischen alle Offsets verschoben sind weil ein anderer Benutzer einen neuen Record erstellt hat).

Also Adressierung per Offset scheint keine Zukunft zu haben.

Vielleicht findet sich ja mal ein besserer Algorithmus zum Ermitteln des vorigen und nächsten Records, wenn ein einzelner Record per PK angefragt wurde. Also Frage an die SQL-Experten: Wie kriege ich (ohne alle Records abzurufen) den Offset, wenn ich nur den PK kenne? Zum Beispiel führt der Report contacts.Persons (vereinfacht) zu einem SQL-Query SELECT * from Persons ORDER BY name. Ein einzelnes Element kriege ich mit SELECT * from Persons ORDER BY name where id = 123. Wenn ich den Offset kennte (sagen wir mal er sei 25, könnte ich anschließend mit zwei einfachen SELECT * from Persons ORDER BY name offset 24 limit 1 und SELECT * from Persons ORDER BY name offset 26 limit 1 den vorigen und nächsten Record abfragen. Aber die Frage ist: wie finde ich raus, dass ein Person mit id = 123 der 25. Record ist?

Ich könnte auch festlegen, dass Detail-Fenster von Reports mit über 200 Zeilen keine Previous/Next-Buttons haben.

Ich könnte das auch pro Report konfigurierbar machen: Report.show_prev_next.

24.10 Uhr : Wow, eigentlich wollte ich die Ideen nur schnell aufschreiben, aber dann konnte ich es nicht lassen und habe begonnen sie zu implementieren. Erste Erfolgserlebnisse. Check-In.

TODO:

  • er skippt nur bis zum 10. Record (also der ar in elem2rec macht wahrscheinlich ein ungewolltest LIMIT)

  • first und last funktionieren noch nicht

  • quickfilter und csv-Buttons wie in der Listenansicht.

  • Button um in die Listenansicht zurück zu wechseln? Eigentlich muss man dazu ja das Fenster schließen.

  • Bei jedem neuen Record macht er drei unnütze Ajax-Calls für die Slave-Grids, die doch im ersten Reiter gar nicht angezeigt werden (z.B. http://127.0.0.1:8000/api/dsbe/StudiesByPerson?_dc=1279746233056&fmt=json&mt=&mk=200022)