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

[sma]

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

[Y0Gi]

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.

[sma]

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

[Leonidas]

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.

[sma]

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

[mitsuhiko]

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.

[sma]

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