Das deutsche Python-Forum

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.

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.

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:

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>

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 stehen
Code: 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()}

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.
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>

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...

Unterschied: endif/endfor statt Einrückung, weil das wesentlich weniger verwirrt

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 unterlassen

Wenn man sich nach Endmarken sehnt und das einrücken lästig findet, sollte man vielleicht Ruby programmieren ...

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

) ist die Gruppe der Python-Programmierer und nicht "irgendwelcher Benutzer". Und diese Python-Programmierer lieben es nunmal Python-Code zu schreiben, mit einrücken und ohne Endmarken ... und das kann man bei mir und anderen System halt ... Das finde ich echt mal entspannend und entwirrend

THExSYSTEM hat geschrieben:Verwirrend?! Im Gegenteil! *snip*

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.

Einrückung ist toll, aber nur, wenn die Syntax das Unterstützt. (SG|X)ML tun das nicht.

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...

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.

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

Übrigens, Breve sieht auch interessant aus, allerdings überzeugen mich die Beispiele nicht, warum eine innere DSL einer externen DSL überlegen sein soll. Die vielen [ ] sind nun auch nicht gerade die Eleganz in Person.

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.

Y0Gi hat geschrieben:Einrückung:
Da diese in SGML/XML eine ganz andere Bedeutung als in Python erfährt [...]

Ich würde gerne einmal ein Beispiel dafür sehen.

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)

Hier müsste man von jeder Zeile die initiale Einrückung abziehen und es könnte sein, dass eine andere als die erste Zeile des Blocks diese Einrückung vorgibt.

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"}/

Hier fällt mir keine gute Lösung ein, außer auf eine ansonsten ignorierbare Leerzeile zwischen den beiden Tags zu achten.

Ich glaube, Haml rettet sich, indem es für inline-Tags alternativ auch Textile oder Markdown o.ä. erlaubt.

Stefan

sma hat geschrieben:
Y0Gi hat geschrieben:Einrückung:
Da diese in SGML/XML eine ganz andere Bedeutung als in Python erfährt [...]
Ich würde gerne einmal ein Beispiel dafür sehen.

SGML ist mir egal, aber bei XHTML spielen Leerzeichen doch eigentlich keine Rolle.

Ich denke dass meinte Y0Gi gerade - XML ist Einrückung egal, durch das besprochene Templatesystem würden auf einmal Einrückungen ein Syntaxelement werden.

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.

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.

Stefan

Leerzeichen spielen eine Rolle.

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>

Und solche Tricksereien braucht man früher oder später. Gerade bei Bildern etc.

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:

Code: Alles auswählen

%div
  %a{href="foo"} blub
  %a{href="bar"} blub

Will man ein Leerzeichen zwischen den beiden <a>s haben, muss man das auch explizit hinschreiben:

Code: Alles auswählen

%div
  %a{href="foo"} blub
  = " "
  %a{href="bar"} blub

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:

Code: Alles auswählen

%div
  #{link_to "blub", foo_url} #{link_to "blub", bar_url}

Stefan

Das deutsche Python-Forum

pyHTMLutils - HTTP-Server & HTML-Template-Engine - MVC