= [20100219 ←] [20100222 22.02.2010] [20100223 →] =

Überlegungen am Vorabend.

  • Also wenn ich fürs PropertiesWindow sowieso einen Report instanziere, dann sollte ich den bisherigen Code zur Initialisierung des Editors ebenfalls über den Report machen. Da kommt also ein for pv in self.rh.request(master=model,master_instance=None)

  • Das PropertiesWindow sollte eigentlich gar nicht im Report gespeichert werden, sondern im Model. Momentan wird es für jeden Report instanziert; das stört zwar nicht, aber ist unnötig. Also der Code aus setup_report() gehört irgendwo anders hin, und zwar nach Lino.setup(). Oder genauer gesagt nach reports.setup(), ähnlich wie ich schon ein _lino_model_report in die Models rein propfe. Also _lino_properties_window.

  • Irgendwie unschön ist, dass man von außerhalb den PropValuesByOwner befragen muss, ob er Records für master_instance=None enthält. PropertiesWindow sollte doch eigentlich selber sagen, ob es für ein gegebenes Modell angelegt werden will.

  • Momentan ist es auch so, dass man den Server neustarten muss, wenn man Änderungen in der Konfiguration der Eigenschaften gemacht hat. Also wenn man eine neue Eigenschaft anlegt, oder auch nur eine neue Auswahlmöglichkeit einer Eigenschaft. Andererseits wäre es dumm, für jede Anzeige des Ei-Editors eine Abfrage zu machen um solche seltenen Änderungen automatisch zu erkennen.

Nein, das PropertiesWindow kann nicht Model gespeichert werden, weil eventuell mehrere UIs auf einem Server laufen können. Momentan haben wir zwar nur extui, aber wer weiß ob sich das irgendwann mal ändert. Ein ModelHandle (also einen Descriptor pro Model pro UI) braucht Lino aber momentan noch nicht. Also tun wir das PropertiesWindow doch in den ReportHandle.

Aha, und jetzt kommt was Neues: Reports ohne Layout. PropValuesByOwner hat ja die Sammelklasse PropValue als model, also kennt er keine Kolonne value. Ich könnte eine Methode PropValue.value definieren, aber deren return_type wäre ja pro Instanz veränderlich. Das wäre unsinnig. Das Neue ist, dass dieser Report gar keine Layouts haben kann. Neues Attribut Report.use_layouts: wenn das False steht, dann kriegt der ReportHandle kein choice_layout, row_layout und layouts.

Neue Methode reports.ReportHandle.request(). Die gibt also einen “primitiven” ReportRequest zurück. Bis auf weiteres unterstützt der Ei-Editor übrigens keine benutzerabhängigen Eigenschaften (also Eigenschaften, die manche Benutzer sehen können und andere nicht). So ein Feature wäre wahrscheinlich auch ziemlich unsinnig.

Reports ohne Layout brauchen übrigens auch kein UI und kein Handle. Report.render_to_dict() könnte theoretisch ohne all diesen Kram funktionieren.

Und jetzt muss ich Feierabend machen. Bin in testapps.properties dran, denn irgendwas klappt noch nicht nach den Neuerungen. Das ist für morgen. (Schade, ich hatte gehofft, dass ich heute den Ei-Editor fertig kriege und mit dem Text-Editor anfangen kann…)