20100213 Arbeitsbericht

Ich habe die Idee, wie ich ContextAwareChoices besser implementieren kann (Issue 100): Die city_choices-Methode im Beispiel wird eine @staticmethod (braucht keine Instanz) und definiert selber ihre Liste von Argumenten, deren Name mit einem existierenden Feld übereinstimmen muss. Mit dieser API ist es möglich, dass das UserInterface (d.h. extjs) seine Combo-Boxen nicht jedesmal neu lädt, wenn der current_record ändert. Momentan wird beim Blättern durch Person (z.B.) der Context für jede Person neu geladen, auch wenn die neue Person im gleichen Land ist. Weil extjs bisher nicht wissen kann, dass für die Auswahlliste von city lediglich das Land wichtig ist.

Aber wie kann ich in Python die Namen der deklarierten Argumente (formal parameter list) einer Funktion rausfinden? Mit inspect? Nö, viel einfacher: die stehen in fn.func_code.co_argcount. Ich probiere es aber lieber doch mal aus: http://code.google.com/p/lino/source/browse/tests/misc/choices.py

Die Hauptarbeit wird darin bestehen, das momentane System der Comboboxen in extjs nochmal umzukramen…

Dabei werde ich auch nochmal probieren, ob ich die Städtenamen in cityHidden nicht doch ausnutzen kann, um den Text der ComboBoxen anzuzeigen. Es ist einfach zu dumm, dass er beim einfachen Blättern durch die Persons jedesmal einen Request machen muss, um die Stadt anzuzeigen. In Zukunft kommt der Request dann zwar nur noch, wenn das Land der Person ändert. Aber auch das ist noch unnötig, weil die komplette Liste ja erst nötig ist, wenn man die Auswahlliste aufklappt.

Frage am Rande: Bin ich nicht vielleicht das Rad neu am erfinden? Gibt es vielleicht doch schon andere Lösungen für das Problem der ContextAwareChoices?

Das [http://www.djangosnippets.org/snippets/26/ Django Snippet 26] (Getting dynamic model choices in newforms) ist zunächst keine, aber in den Kommentaren werden zwei verschiedene Anzätze beschrieben “how to filter a lookup table based on a value passed at run time”. Vor allem die Idee eines gewissen beuc ist bemerkenswert:

class MyForm(forms.ModelForm):
    class Meta:
        model = my_models.MyModel

    def __init__(self, *args, **kwargs):
        dynarg = kwargs.pop('dynarg')
        self.base_fields['myfield'].empty_label = None
        self.base_fields['myfield'].queryset = \
          my_models.MyField.objects.filter(myfilter=dynarg)
        super(MyForm, self).__init__(*args, **kwargs)

Also er setzt FormField.queryset beim Instanzieren der Form.

Diese Idee nützt mir leider für ExtJS nichts, weil der Client die Dynamisierung machen muss (bzw. die Entscheidung, ob ein neuer Request nötig ist), d.h. die Entscheidung muss in JavaScript implementierbar sein.

—

Weiter mit Issue 103 (das ich gerade erst erfasst habe, obschon ich ja schon die ganze Woche daran arbeite…) Mir ist inzwischen klar, dass ich das unmöglich mit einer normalen Grid geregelt kriege, sondern dafür muss eine Ext.grid.PropertyGrid her. Meine ersten Kennenlern-Versuche sind [http://code.google.com/p/lino/source/browse/extjs-showboxes/20100213_PropertyGrid.html hier].

Wieso finde ich PropertyGrid.customRenderers nicht im Quellcode? Aha, weil es eine neue Version 3.1.1 gibt. Das Feature ist offenbar neu, obwohl es nicht in den [http://www.extjs.com/products/extjs/CHANGES_ext-3.1.1.html Release notes] steht.

PropertyGrid.propertyNames : super, dass es das gibt. Ich glaube, dass sollte ich prinzipiell benutzen, damit ich in mehrsprachigen Installationen keine Probleme kriege. Aber auf einsprachigen Sites (und insbesondere DSBE) hat das die lästige Nebenwirkung, dass ich mir für jede Eigenschaft einen internen Namen ausdenken muss. Hmm… also jedenfalls muss Property.label optional bleiben.

Na das war ja einfach. Gefällt mir.

Aber wie integriere ich das nun in Lino? Das ist mal was ganz Neues. Das wird eine neue Art von Element, das in einem PageLayout benutzt werden kann. Kommt also nach layouts.py als Klasse PropertyGrid. Die Klasse kann bis auf weiteres komplett leer sein, weil sie immer die properties.PropValue des Report.model anzeigt. Da sind also keine Konfigurationsoptionen. Und in extjs.py kommt eine neue Klasse PropertyGridElement. Die muss sich um das Einbinden kümmern. Jetzt wird es spannend. Aber ich geh trotzdem erst mal schlafen.