encoding in XML-File und MiniDOm
Naja, dafür gibt's unter Umständen überflüssige Tags auf die er achten muss.gerold hat geschrieben: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.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.
Genau so ist's bei Kid auch.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.
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.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.
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.
Mag sein, das DTML diese Probleme hat. Kid-Vorlagen sind immer gültiges XML.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.
So engstirnig waren die Kid-Entwickler nicht. Die wollten ein XML-Vorlagen-System und nicht nur was für Webseiten.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>
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.
- gerold
- Python-Forum Veteran
- Beiträge: 5555
- Registriert: Samstag 28. Februar 2004, 22:04
- Wohnort: Oberhofen im Inntal (Tirol)
- Kontaktdaten:
Hi Jens!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 ???
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.
lg
Gerold
http://halvar.at | Kleiner Bascom AVR Kurs
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Ist __doc__ jemand den ich kennen sollte?blackbird hat geschrieben:Ich kenn nur die Aussagen von __doc__ über ZOPE und werde deswegen die Finger davon lassen
Blackbird, vielleicht postest du ja was __doc__ so gesagt hat (ggf. zusammengefasst), das würde mich interessieren.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
- gerold
- Python-Forum Veteran
- Beiträge: 5555
- Registriert: Samstag 28. Februar 2004, 22:04
- Wohnort: Oberhofen im Inntal (Tirol)
- Kontaktdaten:
Hi BlackJack!
Aber, so schön das auch klingt -- ich sehe alleine schon in der Existenz des PI-Blockes eine leicht übersehbare Gefahr. --> Wer hindert den Programmierer daran, eine Datenbankabfrage innerhalb dieses PI-Blockes durchzuführen? In dem Moment, in dem so etwas passiert, wurde das Programm schwerer Erweiterbar. Das "Warum" habe ich in einem anderen Beitrag zu diesem Thema schon erklärt. Programmierer sind faule Wesen. Man denkt nicht immer an die Wartbarkeit oder Erweiterbarkeit eines Programmes. Es gibt auch nicht immer einen genauen Plan, wie die genaue Struktur eines Programmes auzusehen hat. Oft setzt man sich einfach vor den Computer und programmiert nur mit dem Ziel vor Augen darauf los.
Wird der Programmierer vom Vorlagensystem dazu gedrängt, Code mit Programmlogik in eigene Objekte (Python-Scripts, Module, ...) auszulagern, dann wird das Programm automatisch besser wartbar, auch wenn nur mal so darauf los programmiert wurde.
Ich schrieb HTML, dachte aber an XML. Diese Fähigkeit hat Kid wahrscheinlich von TAL geerbt.
lg
Gerold
Diese Trennung ist sehr zu begrüßen. Das ist sicher ein Pluspunkt für Kid. So wird es schwieriger, typischen PHP-Kauderwelsch zu programmieren.BlackJack hat geschrieben: 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.
Aber, so schön das auch klingt -- ich sehe alleine schon in der Existenz des PI-Blockes eine leicht übersehbare Gefahr. --> Wer hindert den Programmierer daran, eine Datenbankabfrage innerhalb dieses PI-Blockes durchzuführen? In dem Moment, in dem so etwas passiert, wurde das Programm schwerer Erweiterbar. Das "Warum" habe ich in einem anderen Beitrag zu diesem Thema schon erklärt. Programmierer sind faule Wesen. Man denkt nicht immer an die Wartbarkeit oder Erweiterbarkeit eines Programmes. Es gibt auch nicht immer einen genauen Plan, wie die genaue Struktur eines Programmes auzusehen hat. Oft setzt man sich einfach vor den Computer und programmiert nur mit dem Ziel vor Augen darauf los.
Wird der Programmierer vom Vorlagensystem dazu gedrängt, Code mit Programmlogik in eigene Objekte (Python-Scripts, Module, ...) auszulagern, dann wird das Programm automatisch besser wartbar, auch wenn nur mal so darauf los programmiert wurde.
BlackJack hat geschrieben: Mag sein, das DTML diese Probleme hat. Kid-Vorlagen sind immer gültiges XML.
[...]
So engstirnig waren die Kid-Entwickler nicht. Die wollten ein XML-Vorlagen-System und nicht nur was für Webseiten.
Ich schrieb HTML, dachte aber an XML. Diese Fähigkeit hat Kid wahrscheinlich von TAL geerbt.
Dieser kleine Unterschied *erschwert* es dem Webdesigner, einen Fehler zu machen. Es ist sicher nicht die Welt, aber wieder eine Kleinigkeit, die das Leben leichter machen kann. Hierbei handelt es sich aber eher um eine Glaubensfrage, die man wahrscheinlich nicht klären kann.BlackJack hat geschrieben: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.Code: Alles auswählen
<p> The current time is <span tal:content="python: time.strftime('%C %c')">[Time]</span>. </p>
Man kann mit "tal:omit-tag" die TAG-Struktur löschen und nur den Inhalt übrig lassen. Das geht mit Kid sicher auch.BlackJack hat geschrieben:Problematisch wird's wenn es nicht HTML ist und man nicht einfach mal ein "effektloses" Tag wie <span> zu Verfügung hat.
lg
Gerold
http://halvar.at | Kleiner Bascom AVR Kurs
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
-
- User
- Beiträge: 1790
- Registriert: Donnerstag 28. Oktober 2004, 16:33
- Wohnort: Graz, Steiermark - Österreich
- Kontaktdaten:
#python.de ^^Leonidas hat geschrieben:Ist __doc__ jemand den ich kennen sollte?blackbird hat geschrieben:Ich kenn nur die Aussagen von __doc__ über ZOPE und werde deswegen die Finger davon lassen
Blackbird, vielleicht postest du ja was __doc__ so gesagt hat (ggf. zusammengefasst), das würde mich interessieren.
Er verwendet das jeden Tag für die Firma und es ist laut seinen Aussagen ab einer bestimmten Projektegröße "unmaintainable".
TUFKAB – the user formerly known as blackbird
Aber man hat in dem Fall in der Vorlage ein Tag, das da nicht hingehört und vielleicht Probleme mit anderen Programmen zum Editieren der Vorlage bringen kann.gerold hat geschrieben:Man kann mit "tal:omit-tag" die TAG-Struktur löschen und nur den Inhalt übrig lassen. Das geht mit Kid sicher auch.BlackJack hat geschrieben:Problematisch wird's wenn es nicht HTML ist und man nicht einfach mal ein "effektloses" Tag wie <span> zu Verfügung hat.
- jens
- Python-Forum Veteran
- Beiträge: 8502
- Registriert: Dienstag 10. August 2004, 09:40
- Wohnort: duisburg
- Kontaktdaten:
Also ich weiß das die FH-Düsseldorf ihr komplette externe und internen Seiten in Zope realisieren will: http://www.zwec.orgblackbird hat geschrieben:Er verwendet das jeden Tag für die Firma und es ist laut seinen Aussagen ab einer bestimmten Projektegröße "unmaintainable".Leonidas hat geschrieben:Blackbird, vielleicht postest du ja was __doc__ so gesagt hat (ggf. zusammengefasst), das würde mich interessieren.blackbird hat geschrieben:Ich kenn nur die Aussagen von __doc__ über ZOPE und werde deswegen die Finger davon lassen
Das Project ist wirklich riesig! Allerdings bauen dich auch schon seid Jahren, aber das hat andere Gründe