Seite 1 von 2

Re: Doch nicht so einfach...

Verfasst: Mittwoch 16. November 2005, 17:58
von mitsuhiko
gerold hat geschrieben:Nach dieser irreführenden Fehlermeldung zu schließen, ist ein Leerzeichen zwischen "test." und "toprettyxml" zu viel.

Code: Alles auswählen

In [1]: "spam" .decode("utf-8")
Out[1]: u'spam'

In [2]: "eggs".decode("utf-8")
Out[2]: u'eggs'
8)

Re: Doch nicht so einfach...

Verfasst: Donnerstag 17. November 2005, 01:59
von BlackJack
gerold hat geschrieben:
polarsonnenschein hat geschrieben:

Code: Alles auswählen

Traceback (most recent call last):
   File "test41.sbl", line 11, in ?
     test_xml.writelines(test. toprettyxml(indent='  ', encoding="utf-8"))
   File "/cc3.45/E027/cx/sbl/py/xml/dom/minidom.py", line 56, in toprettyxml
     writer = codecs.lookup(encoding)Ä3Ü(writer)
 LookupError: no codec search functions registered: can't find encoding
 Error in evalueating test41.sbl
Nach dieser irreführenden Fehlermeldung zu schließen, ist ein Leerzeichen zwischen "test." und "toprettyxml" zu viel.
Das dürfte kaum den Fehler provozieren. Der Punkt-Operator ist genau das: ein Operator. Wie '+' oder '-' oder '*' auch, es ist egal wieviele Leerzeichen oder sogar Zeilenumbrüche davor und dahinter stehen.

Code: Alles auswählen

In [1]: a = 'hallo'

In [2]: a.upper()
Out[2]: 'HALLO'

In [3]: (a
   .3.:            .
   .3.:  upper
   .3.:  (
   .3.:           )
   .3.: )
Out[3]: 'HALLO'

Re: Doch nicht so einfach...

Verfasst: Donnerstag 17. November 2005, 09:44
von gerold
blackbird hat geschrieben:

Code: Alles auswählen

In [1]: "spam" .decode("utf-8")
Out[1]: u'spam'

In [2]: "eggs".decode("utf-8")
Out[2]: u'eggs'
Ups, das wusste ich noch nicht. :oops: :oops: --> denke doch noch zu sehr in "Visual Basic".

lg
Gerold
:-)

Verfasst: Donnerstag 17. November 2005, 15:49
von Leonidas
Aber da sollte man, obwohl es möglich ist, keine Leerzeichen reinmachen. Ich habe zum Glück auch noch keinen Quelltext gesehen, der sowas machen würde.

Verfasst: Donnerstag 17. November 2005, 22:30
von BlackJack
Ich habe das schon gesehen und auch schon gemacht. Es ist eine relativ "natürliche" Bruchstelle wenn man Methodenaufrufe auf Ergebnisse von vorhergehenden Aufrufen aneinanderkettet und das auf mehrere Zeilen verteilen möchte.

Code: Alles auswählen

(spam.frobnicate()
    .fooble()
    .stringify()
    .flobs())
Wenn jetzt jeder Aufruf noch zwei bis fünf Argumente mit auf den Weg bekommt, dann macht das schon Sinn.

Verfasst: Freitag 18. November 2005, 08:45
von jens
Also ich würde in dem Falle ehr mit "Zwischenergebnissen" arbeiten. Dann weiß man auch besser was passiert ;)
Aber finde ich irgendwie abgefahren, das man Leerzeichen einfach einfügen kann... Klingt aber auch Logisch, wenn "." == ["+", "-", ect.] is ;)

Zurück zum Thema...
Ich weiß das man normalerweise und direker XML mit minidom o.ä. erzeugen kann...
Eine andere herrangehensweise wäre ein Template zu bauen und es mit leben zu füllen... z.B. simpleTAL... Ist vielleicht etwas abgefahren, aber man kann somit alle Arten von XML bauen, wie man es will ;)

Verfasst: Freitag 18. November 2005, 13:23
von Leonidas
BlackJack hat geschrieben:Ich habe das schon gesehen und auch schon gemacht. Es ist eine relativ "natürliche" Bruchstelle wenn man Methodenaufrufe auf Ergebnisse von vorhergehenden Aufrufen aneinanderkettet und das auf mehrere Zeilen verteilen möchte.
Auf mehrere Zeilen verteilt sieht dass schon sinniger aus, jedoch ist es nicht wirklich hübsch :-/

XML kann man auch mit Kid erzeugen. Der Vorteil gegenüber simpleTAL ist, dass es besonders stark in Entwicklung ist, da es für TurboGears benötigt wird.

Verfasst: Freitag 18. November 2005, 13:35
von jens
Na, ich weiß nicht ob das wirklich ein großer Vorteil ist ;) Das heißt soviel, das die API/Schnittstellen/Funktionalität noch nicht wirklich feststehen bzw. noch nicht ausgiebig getestet sind???

Ich will nicht behaupten simpleTAL ist das beste überhaupt... Dafür hab ich bisher noch nicht so viel damit gearbeitet. Aber es ist nun mal eine Standalone Lösung von Zope's TAL, welches schon einigermaßen "alt" ist und somit eigentlich ausgereift sein dürfte...

Andererseite haben sich die KID Entwickler auch erstmal angesehen was es so gibt und vielleicht auch TAL...

Verfasst: Freitag 18. November 2005, 14:14
von Leonidas
jens hat geschrieben:Na, ich weiß nicht ob das wirklich ein großer Vorteil ist ;) Das heißt soviel, das die API/Schnittstellen/Funktionalität noch nicht wirklich feststehen bzw. noch nicht ausgiebig getestet sind???
Nach der Anzahl von Leuten zu schließen, die Kid in TurboGears nutzen sollten Fehler recht schnell gefunden werden. Die API kann sich durchaus noch leicht ändern, jedoch habe ich in der TG Mailingliste gelesen (den genaue Mail kann ich nicht mehr liefern, dort sind zu viele), dass die API bis Kid 1.0 sich nicht mehr sonderlich ändern wird.
Kid homepage hat geschrieben:It was spawned as a result of a kinky love triangle between XSLT, TAL, and PHP.
Na, PHP muss man nicht mögen, aber man muss den PHP-mäßigen Teil von Kid ja auch nicht nutzen (das ist nur die Möglichkeit Python-Code in den Templates zu schreiben).

Verfasst: Freitag 18. November 2005, 14:18
von jens
Leonidas hat geschrieben:(das ist nur die Möglichkeit Python-Code in den Templates zu schreiben)
Wobei das auch mit simpleTAL möglich ist... Das kann auch ganz nützlich sein, weil man einfache Filter damit stricken kann. s. http://www.python-forum.de/viewtopic.php?p=25207#25207

Verfasst: Freitag 18. November 2005, 14:27
von Leonidas
Im Wiki gibt es die Seiten WhatsBorrowed und WhatsDifferent. Dort steht was Kid alles auch aus TAL/ZPT übernommen hat.

Verfasst: Freitag 18. November 2005, 14:38
von gerold
Leonidas hat geschrieben: XML kann man auch mit Kid erzeugen. Der Vorteil gegenüber simpleTAL ist, dass es besonders stark in Entwicklung ist, da es für TurboGears benötigt wird.
Hi!

Also für mich sieht Kid wie TAL ohne Trennung von Code und Content aus. Ob das jetzt wirklich so fortschrittlich ist, möchte ich sehr bezweifeln.
Das geht sogar so weit, dass solche Zeilen möglich sind:

Code: Alles auswählen

<p>
  The current time is ${time.strftime('%C %c')}.
</p>
Jetzt fällt mir auch wieder ein, weshalb ich unter ZOPE kein DTML mehr, sondern nur noch TAL verwende. Solche Mischungen von Content und Code gehen gerne in die Hose oder erschweren die Wiederverwendung von Code. :evil:

:idea: Gerade weil solche Konstrukte *nicht* mit TAL möglich sind, finde ich TAL ausgereifter.

Dann kommt noch das Problem der Übersetzung dazu. Unter Zope kann ich das Tag-Attribut i18n setzten. Schon brauchst du dich um fast nichts mehr kümmern. Der Content wird durch die im Browser eingestellte Sprachversion ersetzt oder kann gezielt ausgetauscht werden. Ich glaube aber nicht, dass das mit *simpleTal* funktioniert. :?

Wie auch immer -- ich glaube, das hat mit der ursprünglichen Frage des OP nichts mehr zu tun. :wink:

lg
Gerold
:-)

Verfasst: Freitag 18. November 2005, 21:46
von BlackJack
Was genau beanstandest Du denn an der zitierten Codezeile? Wie sollte das denn getrennter aussehen? Irgendwo *muss* man letztendlich eine Schnittstelle zu Funktionen/Methoden anbieten.

Verfasst: Samstag 19. November 2005, 13:00
von gerold
BlackJack hat geschrieben:Was genau beanstandest Du denn an der zitierten Codezeile? Wie sollte das denn getrennter aussehen? Irgendwo *muss* man letztendlich eine Schnittstelle zu Funktionen/Methoden anbieten.
Hi @ all!

Ich gehe mit meiner Meinung zu diesem Thema ziemlich mit den Entwicklern von TAL konform. Bei TAL gibt es nur eine Stelle, an der Code sein darf --> als Attribut eines TAGs. So gibt es für den, der die Seite später einmal umgestalten muss, nicht so viel zu bedenken.

Er muss natürlich ein paar Dinge über Tal wissen. Zum Beispiel:

- Wenn im TAG "tal:replace" steht, dann wird der komplette TAG ersetzt. Es bringt also nichts, wenn er eine Änderung als TAG-Content hinein schreibt.

- Wenn im TAG "tal:content" steht, dann wird der Inhalt des TAGs ersetzt. Die TAG-Definition selbst, bleibt erhalten.

Der, der die Seite später mal editiert, muss also nur ein paar Grundregeln beachten um die Seite nicht zu zerstören.

Es kann komplizierter werden, wenn auch noch innerhalb eines TAGs Code stehen kann. Ich kann diese Aussage nicht beweisen, da es sich dabei um eine Bauchsache handelt.
Man kann sich ja mal den Quellcode von vielen ASP- oder PHP-Seiten ansehen, die so im Internet herumschwirren, oder die man selber programmiert hat. Viele sind kaum mehr wartbar, da es kaum oder keine Trennung zwischen Code und Content gibt.

Man kann es auch so sehen: Je schwieriger es dem Programmierer gemacht wird, unschönen Code zu schreiben, desto einfacher ist es für andere, den Code zu lesen. --> Python.

Es gab eine Zeit, das ist noch gar nicht so lange her, da erstellte ich dynamische Internetseiten in Zope mit DTML. DTML ist sehr mächtig und man kann damit auch innerhalb eines Textes Variablen einfügen.

Aber genau diese Möglichkeit, macht dir auf einmal Schwierigkeiten, wenn du innerhalb eines TAGs ein Attribut verändern, hinzufügen oder löschen möchtest. Auch ein WYSIWYG-Editor hat keine Chance mehr, da der Code das TAG so verändert, dass es nicht mehr HTML-konform ist.

Genau über solche Dinge und noch viel mehr, haben sich die Entwickler von TAL, METAL und Co. Gedanken gemacht. Das Ergebnis ist nicht nur eine Vorlagensprache, sondern eine komplette Strategie zur Website-Erstellung.

Wenn ich schon innerhalb eines TAGs einen Teil ersetzen muss, dann sollte dieser Teil auch ungerendert wie gültiges HTML aussehen. Ungeachtet der Möglichkeit, den Text übersetzten zu lassen, könnte der Code in TAL so aussehen:

Code: Alles auswählen

<p>
  The current time is 
  <span tal:content="python: time.strftime('%C %c')">[Time]</span>.
</p>
Ich habe diesen Code, nur mal zum Testen, in den Quellcodebereich des Programmes NVU eingegeben. Danach in die WYSIWYG-Ansicht gewechselt, "[Time]" markiert und auf den Button für "Fett" geklickt. Das Ergebnis aus dem Quellcodebereich sieht so aus:

Code: Alles auswählen

<p>The current time is <span style="font-weight: bold;"
 tal:content="python: time.strftime('%C %c')">[Time]</span>.
</p>
Auch wenn ich jetzt in der Normalansicht von NVU den Text "[Time]" in "[Zeit]" geändert hätte -- der Code würde weiterhin funktionieren.

Einzig das Löschen des kompletten Textes "[Time]" hätte dazu geführt, dass der Code gelöscht worden wäre.

Als ich mich das erste Mal mit Zope beschäftigte, schrie ich sofort nach einem Ersatz für ASP, also der Möglichkeit Code direkt in die HTML-Seite einzugeben. Das ist heute nicht mehr der Fall. Heute bin ich froh, dass ich so viel von der Logik in Python-Skripte ausgelagert habe. Diese kann ich jetzt, ohne Mehraufwand, direkt in anderen Vorlagen wiederverwenden und über XML-RPC oder HTTP aufrufen.

Man stelle sich nur die Möglichkeiten vor, die einem genommen werden, nur weil man Code nicht vom Content trennen wollte.....

Stell dir vor, du erstellst eine HTML-Seite, die dir den Status deiner Server anzeigt. Steckt die Logik nicht in der HTML-Seite, sondern in einem Python-Skript, das von der HTML-Seite aufgerufen wird, dann ist es schon fast ein Kinderspiel, diese Daten von einem Programm auf einem Client-PC per XML-RPC abzurufen und in einem GUI anzuzeigen.

Würde die Logik in der HTML-Seite stecken, dann müsste man entweder die gerenderte HTML-Seite parsen oder dafür nochmal ein eigenes Skript schreiben.

lg
Gerold
:-)

Verfasst: Samstag 19. November 2005, 13:13
von gerold
Weil ich gerade dabei bin, Zope so hoch zu loben. --> Man braucht wahrscheinlich keine fünf Minuten, um Zope unter Windows zu installieren.

Nachdem man das Tutorial ausprobiert hat, hat man schon eine Vorstellung davon, was TAL und METAL sind und wie man damit in kürzerster Zeit komplette Websites erstellen kann.

Das soll die allgemeine Meinung -- Zope ist doch viel zu groß und kann viel mehr als ich für mein Vorhaben brauche. -- ein wenig widerlegen. Man kann damit auch kleine Sites erstellen.

Wenn ich für mein Vorhaben keine Benutzerauthentifizierung brauche, dann muss ich diese ja nicht verwenden. Es ist aber schön, zu wissen, dass es so etwas gibt wenn ich es brauche.

Zum Installieren von Office braucht man länger. Das kann auch viel mehr als die meisten je brauche werden. Trotzdem verwenden viele Word um damit einen Brief zu schreiben.

lg
Gerold
:-)

Verfasst: Samstag 19. November 2005, 20:50
von jens
Einer der Grünge von Leonidas gegen Zope, war sein relativ hoher Resourcenverbrauch... Ich hab da keine Erfahrungen mit, wie siehst du das, als Zope Fan ???

Verfasst: Samstag 19. November 2005, 22:36
von BlackJack
gerold hat geschrieben:
BlackJack hat geschrieben:Was genau beanstandest Du denn an der zitierten Codezeile? Wie sollte das denn getrennter aussehen? Irgendwo *muss* man letztendlich eine Schnittstelle zu Funktionen/Methoden anbieten.
Ich gehe mit meiner Meinung zu diesem Thema ziemlich mit den Entwicklern von TAL konform. Bei TAL gibt es nur eine Stelle, an der Code sein darf --> als Attribut eines TAGs. So gibt es für den, der die Seite später einmal umgestalten muss, nicht so viel zu bedenken.
Naja, dafür gibt's unter Umständen überflüssige Tags auf die er achten muss.
Er muss natürlich ein paar Dinge über Tal wissen. Zum Beispiel:

- Wenn im TAG "tal:replace" steht, dann wird der komplette TAG ersetzt. Es bringt also nichts, wenn er eine Änderung als TAG-Content hinein schreibt.

- Wenn im TAG "tal:content" steht, dann wird der Inhalt des TAGs ersetzt. Die TAG-Definition selbst, bleibt erhalten.

Der, der die Seite später mal editiert, muss also nur ein paar Grundregeln beachten um die Seite nicht zu zerstören.
Genau so ist's bei Kid auch.
Es kann komplizierter werden, wenn auch noch innerhalb eines TAGs Code stehen kann. Ich kann diese Aussage nicht beweisen, da es sich dabei um eine Bauchsache handelt.
Man kann sich ja mal den Quellcode von vielen ASP- oder PHP-Seiten ansehen, die so im Internet herumschwirren, oder die man selber programmiert hat. Viele sind kaum mehr wartbar, da es kaum oder keine Trennung zwischen Code und Content gibt.
Aber diese Trennung ist doch bei Kid auch machbar. Und umgekehrt ist es schwierig die Trennung zu umgehen. Richtig frei Python Quelltext kann man nur als `Processing Instruction` (PI) eingeben, sonst sind nur Aufrufe möglich. Und innerhalb von PIs kann man keine "Ausgaben" machen. Üblicherweise hat man am Anfang eine PI mit den notwendigen ``import`` Anweisungen und dann nur noch Aufrufe von entsprechenden Funktionen die man importiert hat.

Ausser man geht die Sache vom Code her an, dann importiert man in einem Python-Modul das Template und gibt dem die nötigen Werte und Funktionen mit auf den Weg.
Es gab eine Zeit, das ist noch gar nicht so lange her, da erstellte ich dynamische Internetseiten in Zope mit DTML. DTML ist sehr mächtig und man kann damit auch innerhalb eines Textes Variablen einfügen.

Aber genau diese Möglichkeit, macht dir auf einmal Schwierigkeiten, wenn du innerhalb eines TAGs ein Attribut verändern, hinzufügen oder löschen möchtest. Auch ein WYSIWYG-Editor hat keine Chance mehr, da der Code das TAG so verändert, dass es nicht mehr HTML-konform ist.
Mag sein, das DTML diese Probleme hat. Kid-Vorlagen sind immer gültiges XML.
Genau über solche Dinge und noch viel mehr, haben sich die Entwickler von TAL, METAL und Co. Gedanken gemacht. Das Ergebnis ist nicht nur eine Vorlagensprache, sondern eine komplette Strategie zur Website-Erstellung.
So engstirnig waren die Kid-Entwickler nicht. Die wollten ein XML-Vorlagen-System und nicht nur was für Webseiten. :twisted:

Wenn ich schon innerhalb eines TAGs einen Teil ersetzen muss, dann sollte dieser Teil auch ungerendert wie gültiges HTML aussehen. Ungeachtet der Möglichkeit, den Text übersetzten zu lassen, könnte der Code in TAL so aussehen:

Code: Alles auswählen

<p>
  The current time is 
  <span tal:content="python: time.strftime('%C %c')">[Time]</span>.
</p>
[/quote]

Das kann man mit Kid genauso machen. Sieht aber wesentlich unhandlicher aus als die einfache ${...} Ersetzung. Insbesondere wenn es nicht mal Aufrufe sondern wirklich nur Variablenersetzungen sind. Dann sollte das bei XHTML einem Webdesigner keine grossen Probleme bereiten.

Problematisch wird's wenn es nicht HTML ist und man nicht einfach mal ein "effektloses" Tag wie <span> zu Verfügung hat.

Verfasst: Samstag 19. November 2005, 22:45
von mitsuhiko
Ich kenn nur die Aussagen von __doc__ über ZOPE und werde deswegen die Finger davon lassen :?

Verfasst: Sonntag 20. November 2005, 10:58
von gerold
jens hat geschrieben:Einer der Grünge von Leonidas gegen Zope, war sein relativ hoher Resourcenverbrauch... Ich hab da keine Erfahrungen mit, wie siehst du das, als Zope Fan ???
Hi Jens!

Zope ist sicher nicht ohne, was den Ressourcenverbrauch angeht. Bei ca. zehn ständig verwendeten Zope-Instanzen, die Plone als CMS verwenden, auf einem Rechner mit 1 GB RAM dürfte langsam Schluss sein.

Den Verbrauch kann man aber stark reduzieren, wenn man nur die Module (Zope-Produkte) installiert, die man wirklich braucht. Wenn man Plone nicht einsetzt, dann sind das schon mal so um die 30 Produkte weniger. Das macht schon einiges aus.

Man muss auch nicht für jeden Benutzer eine Zope-Instanz anlegen. Zum Entwickeln verwendet man normalerweise eine eigene Instanz. Auch dann, wenn man einem Kunden mehr Rechte geben möchte, so dass dieser Kunde seine eigenen Produkte installieren kann, dann ist es sinnvoll, diesem eine eigene Instanz zu geben.

Eine Zope-Instanz ist besser zwischen den Kunden abschirmbar als einfach nur eine Ordner-Struktur innerhalb einer Zope-Instanz.

Ich verwende Zope auch zum Erweitern eines meiner Programme. Zope läuft im Hintergrund (mit wenigen geladenen Modulen). Über einen Button oder einen Menüpunkt in meinem Programm, wird ein Fenster mit einem Browser-Steuerelement geladen. Dieses Steuerelement lädt eine vorgegebene URL, die eine Zope-HTML-Seite anzeigt. Das läuft richtig schnell und hat den Vorteil, dass jeder mein Programm anpassen und erweitern kann. Er/sie muss nur HTML und ein wenig Zope können. :D

lg
Gerold
:-)

Verfasst: Sonntag 20. November 2005, 11:33
von Leonidas
blackbird hat geschrieben:Ich kenn nur die Aussagen von __doc__ über ZOPE und werde deswegen die Finger davon lassen :?
Ist __doc__ jemand den ich kennen sollte?

Blackbird, vielleicht postest du ja was __doc__ so gesagt hat (ggf. zusammengefasst), das würde mich interessieren.