Pakete von Drittanbietern konfigurieren

Ich hatte gestern mit Sebastian das Problem aus einem Python-Paket für Zope 3 (gocept.country) eine ZCML-Konfiguration (konkret: i18n:registerTranslations) relativ zu einem anderen Python-Paket (pycountry) zu spezifizieren.

Leider erlaubt i18n:registerTranslations nur eine relative Pfadangabe zum aktuell konfigurierten Paket. Glücklicherweise gibt es einen generischen Mechanismus in ZCML um Konfigurationsangaben im Kontext beliebiger Python-Pakete auszuführen: das configure-Statement.

Configure-Statements können verschachtelt werden und erlauben die freie Angabe eines Pakets, das für alle darin eingebetteten Anweisungen als Kontext benutzt wird. Das ganze sieht dann folgendermaßen aus:

...
<configure package="pycountry">
<i18n:registertranslations directory="locales">
</i18n:registertranslations>
...


zc.resourcelibrary und virtual hosting

zc.resourcelibrary ist ein exzellentes Werkzeug um automatisch Pakete von Ressourcen (CSS, JS, Bilder) gemeinsam zu registrieren und in eine HTML-Seite (via PageTemplate oder View-Klasse) einzubinden. Dabei werden sogar Abhängigkeiten (z.B. "Meine JS-Files benötigen MochiKit") berücksichtigt.

Da die URLs (CSS verweist auf Bilder) in einer Resource-Library statisch sind, muss man ein klein wenig aufpassen, wie man "Virtual-Hosting-kompatibel" bleibt.

Der kleine Trick besteht darin, alle URLs in CSS-Dateien relativ anzugeben. Dadurch wird die (automatisch berechnete) Basis-URL der Resource-Library ebenfalls auf die statisch enthaltenen Verweise angewandt.

Datenbank-Generationen: Am besten immer initialisieren

Wir merken uns: wenn man in der Zukunft eventuell Datenbankgenerationen in seiner Zope-3-Anwendung/Bibliothek/... benutzen will, dann sofort eine leere Generation anlegen.

Der Grund: Wenn die Generations-Infrastruktur noch nicht initialisiert ist, dann wird, wenn vorhanden, immer die `install`-Methode ausgefuehrt. Diese versetzt die Datenbank aber direkt in die aktuellste Generation.

Hat man keine `install`-Methode und eine neue Datenbank wird die Datenbank ohne irgendetwas zu tun sofort in die aktuellste Generation gehievt.

Im optimalen Fall beginnt man also immer bei 0. Beginnt man aber bei `None`, dann muss man den ersten Migrationsschritt immer noch in der Installation abbilden, was man eigentlich nicht sollte.

Security-Target für Zope 3

Die Common-Criteria-Zertifizierung von Zope 3 geht wieder voran und wir haben einen konkreten Zeitplan, der die Arbeit bis zur Zertifizierung abdeckt. Als Zertifizierungstermin zielen wir März 2008 an.

Als ersten Schritt habe ich heute eine überarbeitete Version des "Security Target" (ST) zum TÜV geschickt und bin mal gespannt ob wir mit unseren Überarbeitungen jetzt eine finale Version produziert haben. Im Dezember wird es dann mit den anderen Dokumenten wie im ST beschrieben weitergehen.

Web-Formulare mit Zope 3

Wir bei gocept bereiten uns gerade auf einen Sprint vor. In diesem Sprint wollen wir die Probleme und Erfahrungen der letzten Projekte aufarbeiten, die sich um Web-Formulare drehen.

zope.formlib ist momentan das Standardpaket mit dem wir arbeiten und bietet eine prinzipiell solide Grundlage. Vor einer Weile ist z3c.form erschienen, was einige Probleme der formlib zu beseitigen scheint. In der Vorbereitung zum Sprint evaluieren wir z3c.form als Grundlage unserer weiteren Bemühungen; wir wolle auf jeden Fall ein existierendes Projekt weiterentwickeln und nicht noch eine Baustelle aufreißen. Neben Code werden wir als Ergebnis auch die Dokumentation gängiger Patterns anstreben.

Hier eine Liste der Probleme die uns momentan umtreiben:

1. Interface-Invariants validieren nur gegen Felder, die der Benutzer gerade bearbeitet hat
   Der Kontext und Werte von Feldern die im Formular nicht enthalten waren stehen nicht zur Verfügung.
   
   
2. Werte nach der Validierung aber vorm Schreiben auf Attribute zu verarbeiten ist nicht möglich (z.B. um Passwörter zu codieren)
   
   • Im gleichen Zusammenhang: Validatoren scheinen etwas merkwürdig zu sein da sie die Daten modifizieren können (sollen).
   • Properties können helfen, sind aber schwierig
   • Evt. müsste man Feldern einen Mutator mitgeben
   • Noch eine Option: getrennte Interfaces mit Adapter bereitstellen um solche Werte ins Schema einfliessen zu lassen und auf dem Adapter eine Property definieren
     
     
3. Constraint-Validierungen haben ein komisches Interface
   • True oder Exception
   • Fehlermeldung steht auf der Exception
   • Einige Constraints melden nur "Value too long" ohne dem Benutzer ausreichend Information zu geben
   • Problem liegt in zope.app.form.interfaces.IWidgetInputError und der Implementierung in der zugehörigen Klasse.
   • Diese Implementierung hält nicht was sie verspricht und das Interface widerspricht der Benutzung in den Tests bzw. im View.
   • Aufgabe: WidgetInputError sauber machen, so dass über die doc()-Methode eine i18n-MessageID zurückgeliefert wird.
     
     
4. Layout-Engine
• Eine getrennte Komponente um Formulare im Stil unseres Produktes "Jucon" zu layouten/generieren
  
  
5. Widget-Definitionen
• Interfaces der Widgets aus zope.app.form sind nur intern und via Subclassing gemacht
• Wie verhält sich z3c.form in dieser Hinsicht?
• Anscheinend sind alle Widgets neu definiert.
  
  
6. Formulare mit ergänzenden Inhalten sind unsauber/unflexibel
• Z.B. beim Einbinden von Suchergebnissen
  
• Hier können Content-Provider oder Viewlets helfen.
• Viewlets sind aber aufwändig zu deklarieren.
  
  
7. Abhängig definierte Felder
   
   • Das typische Master-Slave-Szenario: Wert in Feld A auswählen so dass Feld B mit davon abhängigen Optionen gefüllt wird, natürlich via JavaScript
     
   • z3c.form und z3c.formjs scheint dafür noch keine fertige Lösung zu haben

Stabilisierung von Zope 3.4

Zope 3.4 befindet sich seit einiger Zeit in der Stabilisierungsphase, wobei unser halbjährlicher Zyklus für den "Big Tree" mal wieder nicht eingehalten werden kann.

Mit Zope 3.4 stehen alle Zope-Pakete jetzt als Python-Eggs zur Verfügung, so dass man sich für seine Anwendung genau die Elemente aussuchen kann, die man benötigt. Zope wurde in etwa 180 kleine Pakete zerteilt, die nun jeweils ihren eigenen kleinen Release-Zyklus erhalten. Dadurch kann bei Egg-basierter Entwicklung auf Fehler und neue Funktionen deutlich flexibler reagiert werden. Ich finde, dass dies ein exzellenter Schritt ist um die Flexibilität von Zope 3 auf einer weiteren Ebene zugänglich zu machen.

Bevor demnächst die Zope 3.4 Release Candidate veröffentlicht werden kann gibt es eine TODO-Liste die alle noch als stabil zu releasenden Eggs auflistet. Mit diesen Eggs wird dann das klassische Release erzeugt. Diskussion zur Stabilisierung findet auf zope3-dev, ungefähr hier statt.

Abhängigkeiten der Zope-Pakete

In unserem wöchentlichen Workshop bei gocept befassen wir uns seit einer Weile damit die Abhängigkeiten der offiziellen Zope-Pakete aufzuräumen. Einige der Pakete im zope.*-Namensraum haben beispielsweise Abhängigkeiten nach zope.app.*. Diese Abhängigkeiten erschweren die Wiederverwendbarkeit solcher Pakete außerhalb des Zope-Applikationsservers und sind daher unerwünscht.

Wir haben inzwischen alle Pakete analysiert und den Zustand im Zope-3-Wiki dokumentiert. Für Pakete mit ungünstigen Abhängigkeiten suchen wir jetzt Möglichkeiten diese aufzulösen.

Für zope.annotation und zope.location haben wir bereits Lösungen erarbeitet, die momentan hier und hier diskutiert werden. In den nächsten Wochen wird dieses Thema dann hoffentlich für die Pakete des zope.*-Namensraums erledigt.

Update (31.08.2007):
Inzwischen sind nur noch wenige Pakete mit akutem Handlungsbedarf übrig: zope.traversing, zope.viewlet, zope.sendmail haben immernoch Abhängigkeiten nach zope.app.* - viewlet und sendmail werden noch diskutiert.

Weiterhin gibt es noch einen ziemlichen Ausnahmefall: zope.formlib - dort gibt es einige systematische Abhängigkeiten nach zope.app.* die nicht ohne weiteres aufgelöst werden können.

Im Verlauf unserer Bemühungen ist noch einmal das Thema hochgekommen ob die strikte Trennung zope.*/zope.app.* wirklich gewollt ist:
http://mail.zope.org/pipermail/zope3-dev/2007-August/023349.html