Layout von Detail-Fenstern : in Lino sind die “Zeilen” momentan ja immer im “Blocksatz” (also links- und rechtsbündig). Das ist unkonventionell: alle RIA die ich kenne, machen ihre Formulare nur linksbündig.
HtmlEditor oder TextArea? Der HtmlEditor verursacht deutliche Performanceeinbußen beim Bildschirmaufbau von Detail-Fenstern. Die Wahl sollte konfigurierbar sein. Markup auch.
“About”-Fenster mit thanks_to() muss irgendwo sichtbar gemacht werden.
In Insert-Fenstern machen Grid-Elemente keinen Sinn. Die können keine Daten enthalten, weil der Record noch keinen primary key hat.
Das Detail-Fenster sollte nun auch einen permalink_name bekommen. Allerdings muss ich noch überlegen, ob und wie er sich dann merken soll, auf welchem Record er steht.
lino.test_apps.properties funktioniert nicht, scheinbar ist actors.discover() nicht aufgerufen worden.
Das Detail-Fenster sollte vielleicht par défaut nicht im Editier-Modus sein, sondern unten ein Button “Edit”, und erst wenn man darauf klickt, werden alle Felder editierbar (und der Record in der Datenbank blockiert), und unten stehen dann zwei Buttons “Save” und “Cancel”. Wobei darauf zu achten ist was passiert, wenn man während des Bearbeitens in der Grid auf eine andere Zeile klickt. Dann muss er am besten das Detail-Fenster speichern, und falls dort ungültige Daten stehen, in der Grid den Zeilenwechsel verweigern.
Report.date_format muss in der Syntax des UI (d.h. ExtJS) angegeben werden.
Prüfen, ob Dokumentvorlagen im XSL-FO-Format besser wären. Apache FOP als Formatierer. Warum OpenOffice.org nicht schon lange XSL-FO kann, ist mir ein Rätsel. AbiWord dagegen soll es können (laut 1 und 2).
Inwiefern überschneiden sich lino.modlib.system.models.SiteConfig und django.contrib.sites?
Actions: - Aktionen brauchen nicht unbedingt in lino.reports.Report.do_setup() instanziert zu werden. Von den Standard-Aktionen GridEdit, DeleteSelected usw. reicht eine einzige Instanz. Action.actor käme dann weg, und Action.__str__() könnte dann in dieser Form nicht mehr benutzt werden. - Action.name ist ja im Grunde ein kurzer Name, der pro Actor identifizierend ist. Der Vorteil ist, dass man sich beim Entwerfen von Reports keinen solchen Namen auszudenken braucht, also dass der Programmierer einer Aktion auch deren Namen festlegt. Wenn zwei verschiedene Aktionen den gleichen Namen haben, wird nur die letzte beibehalten und eine Warnung in der lino.log gemacht. - Übersicht der Aktionen, die momentan benutzt werden:
Klasse |
Name |
|
|---|---|---|
actions.Action |
||
mixins.PrintAction |
||
mixins.DocumentAction |
Dokument für diesen Record anzeigen (vorher falls nötig generieren) |
|
mixins.ImageAction |
image |
Bild für diesen Record anzeigen |
reports.ListAction |
||
GridEdit |
grid |
Report im Listeneditor zum Bearbeiten anzeigen |
ShowDetailAction |
detail |
Diesen Record in Detail-Fenster zum Bearbeiten anzeigen |
InsertRow |
insert |
Insert-Fenster anzeigen (mit leeren Feldern bzw. Standardwerten, und mit OK-Button) |
SubmitDetail |
SubmitDetail |
OK-Button in detail |
SubmitInsert |
SubmitInsert |
OK-Button in insert |