20100208 Arbeitsbericht¶
Heute habe ich zuerst mal in den Tests weiter aufgeräumt. Die waren ja nicht mehr zu gebrauchen. Der Impuls dazu war, dass ich für lino.modlib.properties wohl am besten mit ein paar ordentlichen Tests beginne.
Wieso erkennt der Testrunner den docstring von lino.modlib.properties.modules nicht als Test? Neue lino.test_apps.properties und docstring dort rein. Das wäre sowieso bald nötig geworden, weil ich zum Testen eine weitere Tabelle brauche. Aber Hackerzacker, auch dort findet er ihn nicht! Wie kommt denn das? Liegt es etwa daran, dass ich in settings.INSTALLED_APPS zwei Applications habe, die auf ‘.properties’ enden? Nein. Liegt es an der Indentierung der Testsequenzen? Vielleicht. Aber der Fehler ist plötzlich wieder verschwunden, ohne dass ich wüsste, wie ich das gemacht habe… Ich schätze mal, das liegt mal wieder daran, dass Djangos Testrunner eine abgespeckte eingefrorene Version von doctests hat (Siehe [http://lsaffre.blogspot.com/2009/10/when-your-django-doctests-never-fail.html 20091015]). Hier noch was, das dieser alte Testrunner nicht verträgt:
>>> favdish.create_values("Cookies\nFish\nMeat\nVegetables")
Er sagt dann:
>>> favdish.create_values("""Cookies
^
SyntaxError: invalid syntax
Das Gleiche sagt er, wenn ich es umformuliere:
>>> favdish.create_values("""Cookies
... Fish
... Meat
... Vegetables""")
Also die neue Methode .create_value() habe ich wegen des doofen Testrunners auslagern müssen. Ich geb aber zu, dass meine .create_values(), die einen mehrzeiligen String erwartet, nicht unbedingt die eleganteste API ist (aber bequem in dpy-fixtures).
Aber weiter mit den Tests für lino.modlib.properties (die also jetzt [http://code.google.com/p/lino/source/browse/src/lino/test_apps/properties/models.py hier] stehen).
Habe begonnen, Report.as_text() wieder ans Laufen zu bringen. Aber das ist relativ viel Arbeit. Das lass ich vorerst mal offen, denn es gibt Wichtigeres zu tun.
properties.PropValuesByOwner().get_queryset(fred) kann momentan nicht funktionieren, weil Report.model keine abstrakte Klasse sein darf. Ich könnte freilich PropValue.Meta.abstract ausschalten, aber dann hätte ich für jeden einzelnen Wert einer jeden Eigenschaft zwei Records in zwei verschiedenen Tabellen. Neues Issue 101 (Reports on abstract models).
Ich frage mich, ob ich mit meinem lino.modlib.properties nicht das Rad neu am erfinden bin. Aber Google meldet zu “django generic properties” nichts Interessantes. Das Wort “generic” wird in Django meistens im Kontext von “generic views” benutzt, die mit properties nichts zu tun. Und bei “properties” denken die meisten Django-Benutzer an Python properties. Höchstens hier (Django ticket #6818) hat jemand ein Problem mit [https://docs.djangoproject.com/en/5.0/ref/contrib/contenttypes/#id1 Generic Relations], und das angeführte Beispiel erinnert an meine Datenstruktur.
Also schreibe ich’s selber. Nach gut 3 Stunden Arbeit halte ich Datenbankstruktur und API für zufriedenstellend.
Was fehlt, ist freilich noch der Eigenschaften-Editor. Vielleicht reicht die bestehende Slave Grid. Die muss jetzt sowieso zuerst mal auf Mausklicks reagieren, indem sie ihren Report in einem eigenen Fenster öffnet. Dnach sehen wir weiter. Aber das kommt morgen…
Ich lag schon im Bett als mir noch auffiel, dass order_by(‘value_text’) ersetzt werden kann durch order_by(‘value’). Das ist besser, weil Fred dann auch 110 Kg wiegen kann. Leider muss das redundante Feld value_text trotzdem bleiben, damit PropValuesByOwner was zum anzeigen hat…