Ich finde es praktisch Codeschnippsel einzupassen. So suche ich mir nur Code via Suchmaschine, passe den an, setze dann noch Template-Marku rein und bin fertig. Das ist mit HAML dann etwas komplizierter. Das ist auch das, was mich von breve etwas abgehalten hat.sma hat geschrieben:Ersteres empfinde ich nicht als Nachteil. Im Gegenteil, ich will ja den Code strukturieren und ggf. durch Hilfsfunktionen abstrahieren und keine fertigen Codeschnipsel einbetten müssen.
pyHTMLutils - HTTP-Server & HTML-Template-Engine - MVC
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
-
- User
- Beiträge: 1790
- Registriert: Donnerstag 28. Oktober 2004, 16:33
- Wohnort: Graz, Steiermark - Österreich
- Kontaktdaten:
Sowas ähnliches gibts in Werkzeug und wir raten von der Verwendung ab, weils besseres gibt: http://werkzeug.pocoo.org/documentation/templates
Unterschied: endif/endfor statt Einrückung, weil das wesentlich weniger verwirrt. Beispieltemplate:
Unterschied: endif/endfor statt Einrückung, weil das wesentlich weniger verwirrt. Beispieltemplate:
Code: Alles auswählen
<h1>$escape(title)</h1>
<ul>
<% for link in links %>
<li><a href="$escape(link.href)">$link.html_title</a></li>
<% endfor %>
</ul>
TUFKAB – the user formerly known as blackbird
- jens
- Python-Forum Veteran
- Beiträge: 8502
- Registriert: Dienstag 10. August 2004, 09:40
- Wohnort: duisburg
- Kontaktdaten:
Auch wenn ich den ersten Ansatz besser finde (Keine Programmlogik in Templates) finde ich den Ansatz zumindest interessant, Python direkt in den Templates zu bauen.sma hat geschrieben:Bei Template-Lösungen gibt es ja zwei Denkschulen für die dynamischen Anteile:
- - Es muss eine eigene Sprache sein, die den Anwender vor sich selbst schützt
- Die volle Mächtigkeit der Programmiersprache soll zur Verfügung stehenCode: Alles auswählen
%html %head %title Site: ${params['action']} %body =include('banner.phtml') %hr/ Rechnung: ${5 * 5} %hr/ %ul -for name in ['Ich', 'Du', 'Er', 'Sie', 'Es']: %li Hallo ${'Chef' if name == 'Ich' else name} %hr/ %p#footer{align="center"} -import time generated at ${time.ctime()}
Wenn schon, dann sollte es aber 100% Python sein... Wie wäre es damit:
Code: Alles auswählen
<head><title>{{ title|escape }}</title></head>
<body>
{% python %}
def bsp(no):
print("Test %s" % no)
for no in xrange(10):
bsp(no)
{% endpython %}
</body>
</html>
Aber wie gesagt, eigentlich bin ich dagegen, das man Programmcode in Template baut...
-
- User
- Beiträge: 6
- Registriert: Samstag 1. Dezember 2007, 20:43
- Kontaktdaten:
Verwirrend?! Im Gegenteil! Verwirrend ist es als Python-Programmierer in Python-nicht-existierende Endmarken zu schreiben und uneingerückten Code zu sehen. Das nenne ich verwirrend! Sollch seltsame Erfindungen sollte man doch bitte unterlassenUnterschied: endif/endfor statt Einrückung, weil das wesentlich weniger verwirrt


Die Zielgruppe meines Template-Systems (falls es überhaupt eine gibt


-
- User
- Beiträge: 1790
- Registriert: Donnerstag 28. Oktober 2004, 16:33
- Wohnort: Graz, Steiermark - Österreich
- Kontaktdaten:
Ich bezeichne mich als Python Programmierer und finde dennoch Einrückung als Syntaxelement für SGML/XML Dokumente einen Graus. Zumindest so, wie das da oben Implementiert wurde. HAML macht das schon etwas besser, ist aber immer noch nicht brauchbar. Auf der einen Seite weil XML selber kein brauchbares Whitespace Konzept hat und man gerade bei HTML Templates immer wieder mal den einen oder anderen Whitespace zwischen Elementen killen muss, damit es nach was aussieht.THExSYSTEM hat geschrieben:Verwirrend?! Im Gegenteil! *snip*
Einrückung ist toll, aber nur, wenn die Syntax das Unterstützt. (SG|X)ML tun das nicht.
TUFKAB – the user formerly known as blackbird
Ich würde es anders formulieren: Mir ist egal, ob man Programmcode einbauen kann oder nicht, aber ich habe es bislang noch nie benötigt. Bedingungen und Schleifen sowie die Möglichkeit, Fragmente einbetten zu können reicht im Allgemeinen.jens hat geschrieben:Also dann man explizit einen Python Code Bereich festlegt. Darin kann man ganz normalen Python Code rein packen.
Aber wie gesagt, eigentlich bin ich dagegen, das man Programmcode in Template baut...
Die Idee mit dem Python-Code sollte sich doch z.B. für Django recht leicht ergänzen lassen. Irgendwie so:
Code: Alles auswählen
@register.tag
def python(parser, token):
nodelist = parser.parse(('endpython',))
parser.delete_first_token()
return PythonNode(nodelist)
class PythonNode(Node):
def __init__(self, nodelist):
self.nodelist = nodelist
def render(self, context):
# stdout in string umlenken
# exceptions fangen...
exec self.nodelist.render(context) in context
# umgelenkten string ausgeben
Stefan
Einrückung:
Da diese in SGML/XML eine ganz andere Bedeutung als in Python erfährt, halte ich es zumindest für unüberlegt, hier einfach ein Konzept zu übernehmen, dass andernorts nicht unbedingt gut passt. Die TE von web.py erfordert meines Wissens Einrückung und das ist echt nicht schön.
Ausnahmen sind spezielle Python-Codeblöcke, in denen man natürlich normales Python inklusive erforderlicher Einrückung benutzen können sollte. Da eine Python-Abart nachzubauen, ist nur ein ungünstiger Layer.
Code in Templates:
Es ist nicht falsch, in Templates auch etwas programmieren zu können (was wiederum auch mit den Fähigkeiten der TE zusammenhängt). Dennoch dient eine TE nicht, wie viele undifferenziert annehmen, der Trennung von Code und Darstellung, sondern der Trennung von "Business"-, wie es so schön heißt, und Darstellungslogik.
Das bedeutet, wenn ich in einem Template Code benötige, um die Ausgabe so und so aufzubereiten, dann muss ich diese Funktionalität da irgendwie reinbekommen - und zwar so, dass ich keinen Code in meinem Controller haben muss, der diese Art der Ausgabe großartig vorbereitet. Für sowas werden oft Hilfsmodule eingebunden und in Templates bereitgestellt, um etwa Dinge wie aufteilen von Inhalten auf mehrere Spalten oder ähnliches zu veranlassen.
Da diese in SGML/XML eine ganz andere Bedeutung als in Python erfährt, halte ich es zumindest für unüberlegt, hier einfach ein Konzept zu übernehmen, dass andernorts nicht unbedingt gut passt. Die TE von web.py erfordert meines Wissens Einrückung und das ist echt nicht schön.
Ausnahmen sind spezielle Python-Codeblöcke, in denen man natürlich normales Python inklusive erforderlicher Einrückung benutzen können sollte. Da eine Python-Abart nachzubauen, ist nur ein ungünstiger Layer.
Code in Templates:
Es ist nicht falsch, in Templates auch etwas programmieren zu können (was wiederum auch mit den Fähigkeiten der TE zusammenhängt). Dennoch dient eine TE nicht, wie viele undifferenziert annehmen, der Trennung von Code und Darstellung, sondern der Trennung von "Business"-, wie es so schön heißt, und Darstellungslogik.
Das bedeutet, wenn ich in einem Template Code benötige, um die Ausgabe so und so aufzubereiten, dann muss ich diese Funktionalität da irgendwie reinbekommen - und zwar so, dass ich keinen Code in meinem Controller haben muss, der diese Art der Ausgabe großartig vorbereitet. Für sowas werden oft Hilfsmodule eingebunden und in Templates bereitgestellt, um etwa Dinge wie aufteilen von Inhalten auf mehrere Spalten oder ähnliches zu veranlassen.
Ich würde gerne einmal ein Beispiel dafür sehen.Y0Gi hat geschrieben:Einrückung:
Da diese in SGML/XML eine ganz andere Bedeutung als in Python erfährt [...]
SGML ist mir egal, aber bei XHTML spielen Leerzeichen doch eigentlich keine Rolle. Ausnahme sind <pre> Blöcke:
Code: Alles auswählen
%h1 unformatiert
%pre.python
def f(n):
return 1 if n == 0 else n * f(n - 1)
Ein anderes Problem sehe ich, wenn man ein Leerzeichen zwischen zwei <img>-Elemente haben will, die man ansonsten so darstellen würde:
Code: Alles auswählen
%p
%img{src="foo.gif"}/
%img{src="bar.gif"}/
Ich glaube, Haml rettet sich, indem es für inline-Tags alternativ auch Textile oder Markdown o.ä. erlaubt.
Stefan
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Ich denke dass meinte Y0Gi gerade - XML ist Einrückung egal, durch das besprochene Templatesystem würden auf einmal Einrückungen ein Syntaxelement werden.sma hat geschrieben:Ich würde gerne einmal ein Beispiel dafür sehen.Y0Gi hat geschrieben:Einrückung:
Da diese in SGML/XML eine ganz andere Bedeutung als in Python erfährt [...]
SGML ist mir egal, aber bei XHTML spielen Leerzeichen doch eigentlich keine Rolle.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Das verstehe ich nicht. Bei Perl ist die Einrückung egal und bei Python ist sie ein Syntaxelement. Na und? Beide Programmiersprachen funktionieren offensichtlich (und sind Turing-komplett und damit auf dieser abstrakten Ebene gleichwertig). Haml ist einfach andere andere syntaktische Form, das Infoset von XHTML darzustellen. Solange das gelingt, ist es doch egal, ob die XML-Syntax von XHTML nun Einrückungen ignoriert oder nicht.Leonidas hat geschrieben:Ich denke dass meinte Y0Gi gerade - XML ist Einrückung egal, durch das besprochene Templatesystem würden auf einmal Einrückungen ein Syntaxelement werden.
Stefan
-
- User
- Beiträge: 1790
- Registriert: Donnerstag 28. Oktober 2004, 16:33
- Wohnort: Graz, Steiermark - Österreich
- Kontaktdaten:
Leerzeichen spielen eine Rolle.
Und solche Tricksereien braucht man früher oder später. Gerade bei Bildern etc.
Code: Alles auswählen
<div>
<a href="foo">blub</a>
<a href="bar">blub</a>
</div>
!=
<div><a href="foo">blub</a><a href="bar">blub</a></div>
TUFKAB – the user formerly known as blackbird
Natürlich spielen in dem Beispiel Leerzeichen eine Rolle - die beiden XML-Dokumente sind ja unterschiedlich. Eine Eigenheit von XHTML ist, dass alle bis auf ein Leerzeichen aber ignoriert werden. Wichtig ist für eine alternative Darstellung nur, dass es für etwas wie Haml eben Repräsentationen für beide Varianten gibt. Die untere Variante (keine Leerzeichen) wäre für mich der Default:
Will man ein Leerzeichen zwischen den beiden <a>s haben, muss man das auch explizit hinschreiben:
Nicht wirklich schön, aber explizit statt implizit und damit IMHO kompatibel zur Python-Philosophie. Eine Trickserei würde ich das nicht nennen.
Bei Rails tuen sich die Leute offenbar etwas leichter, da Links hier typischerweise über eine Hilfsfunktion entstehen, die man leicht einbetten kann:
Stefan
Code: Alles auswählen
%div
%a{href="foo"} blub
%a{href="bar"} blub
Code: Alles auswählen
%div
%a{href="foo"} blub
= " "
%a{href="bar"} blub
Bei Rails tuen sich die Leute offenbar etwas leichter, da Links hier typischerweise über eine Hilfsfunktion entstehen, die man leicht einbetten kann:
Code: Alles auswählen
%div
#{link_to "blub", foo_url} #{link_to "blub", bar_url}