Das deutsche Python-Forum

Keine Ahnung ob sich das vermeiden lässt. Das ersetzen würde ich von einem XML-Template schon erwarten weil es nach dem Parsen keine XML-Entities mehr gibt. Die werden beim Parsen ersetzt.

Ich würde eher erwarten, das sich das irgendwo einstellen lässt ...
Ich weiss zwar nicht genau, ob " " eine XML-Entiät ist, aber es ist auf jeden Fall eine HTML-Entität ...

Und auf zum nächsten Problem:

Wie bringe ich Genshi dazu, XML-Entitäten aus dieser JavaScript-Zeile durch && zu ersetzen ?

&& kann ich ja nicht ins Template schreiben ...

Das JavaScript sollte da überhaupt nicht drin sein, sondern in einer eigenen Datei - dann gibt es das Problem nicht.

Ich bin mir gerade nicht sicher, ob es eine Genshi-Funktion gibt, die Output ins Template einfügt, ohne diesen zu maskieren und stattdessen als gültiges XML anzunehmen. Alternativ könnte eine CDATA-Maskierung des JavaScript-Stücks helfen (die man ja mittlerweile ohnehin bei Inline-JavaScript anstatt nur HTML-Kommentaren zu verwenden scheint).

Dummerweise muss in der HTML-Datei, die am Schluss entstehen soll, auch ein Teil JavaScript rein ...

Aber da ich das Haupt-Template ohnehin in mehrere Dateien aufgeteilt habe, darunter auch eine für den JavaScript-Teil, gibt es eine Lösung:

• JavaScript-Teil in ein Text-Template umwandeln
• Dieses JavaScript-Template separat einlesen und behandeln
• Das Ergebnis als Variable in das XHTML-Template einfügen

Theoretisch müsste es funktionieren ... es ist halt etwas Umständlich ...

midan23 hat geschrieben:Aber: Wenn im Template Fehler enthalten sind, wo landen die Fehlermeldungen von Genshi ?
1) Im Browser -> Ich würde mir einen Schritt sparen
2) Im Kommandozeilen-Fenster -> Ich müsste auf die Webserver-Lösung verzichten

Das kommt ganz darauf an, wo/wie du sie abfängst. Wenn du eine WSGI-Anwendung verwendest, geben die `cgitb`-Middleware von Paste oder der Debug-Modus Werkzeug die Exception im Browser aus. Mit letzterem kannst du da sogar schön ruminspizieren - was aber bei Templatefehlern eher nicht sonderlich viel weiterhilft, da gewöhnlich schon die eigentliche Fehlermeldung auf die entsprechende Stelle im Template hinweist.

BlackJack hat geschrieben:Wahrscheinlich "überleben" die Entities gar nicht, weil sie beim Parsen durch die entsprechenden Zeichen ersetzt werden.

So ist es und ich musste mich auch erst daran gewöhnen. Wenn der Output aber als UTF-8 gesendet wird, ist das kein Problem, da die Zeichen ja legitim sind. OK, bei Dingen wie © oder (ohnehin nicht mehr notwendigen) ü ist das kein Thema, aber   macht in der Tat einen Unterschied. Da greife ich dann zum 'whitespace'-Attribut in CSS was ja eigentlich auch keine schlechte Lösung ist. Wie es mit ­ aussieht, ist eine weitere Frage - aber da Firefox da enttäuschenderweise nichts mit anzufangen weiß, ist das für mich auch vorerst irrelevant.

midan23 hat geschrieben:Kann man das vermeiden ? (Ich würde mein " " gerne behalten ...)

Mir ist kein Weg bekannt, aber frag doch mal im IRC oder auf der Mailingliste. Interessieren würde es mich schon.


Mir ist beim Lesen dieses Themas immer mal wieder FormEncode in den Sinn gekommen. Ich habe es nie benutzt, könnte dir aber, da du jetzt ohnehin einen Webserver gebastelt hast, möglicherweise helfen (oder vielleicht ist es auch schon zu spät).

Ich hab trotzdem mal einen Blick auf FormEncode geworfen ... ist sicher ganz nützlich um Formulareingaben zu validieren, aber nicht so toll, wenn es darum geht HTML-Formulare zu erzeugen ...

Mittlerweile hab ich schon eine erste Version fertig (Heisst: Die Software tut was sie soll, aber taugt nicht wirklich zum Herzeigen ...)

Ausgehend von einer XML-Datei wird eine HTML-Datei erzeugt ... ganz nett, funktioniert auch so weit ... aber:
Der Code ist

• nicht dokumentiert (eigene Faulheit )
• Schwer erweiterbar
• Nicht wirklich übersichtlich

Derzeit arbeite ich an einer zweiten, (hoffentlich) besseren Version.
Ich werde die Eingabe-Elemente entfernen und durch PlugIns ersetzen. Dadurch wird der eigentlich Kern der Anwendung übersichtlicher und ich brauch für ein neues Eingabe-Element keine DTD modifizieren bzw. in gut funktionierendem Code rumpfuschen ...
Ausserdem erleichtert es die Fehlersuche ...

Ich denke, das wird interessant ...

midan23 hat geschrieben:Ich hab trotzdem mal einen Blick auf FormEncode geworfen ... ist sicher ganz nützlich um Formulareingaben zu validieren, aber nicht so toll, wenn es darum geht HTML-Formulare zu erzeugen ...

Kannst ja auch Newforms Extracted nutzen, die zweite, neuere Form-Library aus Django die nun auch ohne Django läuft.

midan23 hat geschrieben:Ich hab trotzdem mal einen Blick auf FormEncode geworfen ... ist sicher ganz nützlich um Formulareingaben zu validieren, aber nicht so toll, wenn es darum geht HTML-Formulare zu erzeugen ...

Genau letzteres hat mir auch nicht gefallen (bzw. schon das Prinzip dahinter) und deswegen habe ich mich stets davon fern gehalten. In einem anderen aktuellen Thread wird ein Genshi-Tutorial genannt, das FormEncode verwendet - und der Validierungs-Part scheint doch simpler und einfacher benutzbar zu sein, als ich dachte. .oO("Das sollten Sie sich mal ansehen, Sir!" )