Da ich neu in der Entwicklung von Front-End-Websites bin, kann ich einiges verstehen, Dinge wie Routen, ORM usw. Was ich nicht verstehe, ist, wie sie alle zusammen spielen. Mein Verständnis ist, es gibt eine Reihe von Komponenten für eine Website mit Pyramid / Django etc:
Eine Templating-Engine: Etwas, mit dem Sie Ihren HTML-Code von Ihrem Code abstrahieren können. Macht Sinn.
SQLAlchemy et al: Ein ORM. Gut.
Ein Renderer. Keine Ahnung.
JS-Bibliotheken: JQuery et al: Keine Ahnung, was sie sind, außer dass sie hübsche Effekte hinzufügen. Wie wirkt das mit der Templating Engine zusammen? Wie interagiert das mit dem gesamten Framework? Kann ich in Pyramid Code für jquery schreiben, oder schreibe ich JS separat, stecke ich meine JS-Datei in meine Vorlage oder ...?
Form-Template-Bibliotheken (formish, formalchemy et al): Wie hängen diese mit dem Gesamtbild zusammen? wo stecken sie an?
Irgendwelche anderen wichtigen Komponenten, die ich vermisse?
Könnte also jemand mir helfen und den Stapel erklären?
1) Eine Templating-Engine: Etwas für Sie abstrahieren Ihren HTML-Code aus dein Code. Macht Sinn.
Es gibt mehrere davon. Mako versucht, viele gebräuchliche Python-Idiome in den Vorlagen zu verwenden, um zu vermeiden, viele neue Konzepte zu lernen. Jinja2 ist ähnlich wie Django, aber mit mehr Funktionalität. Genshi ist, wenn Sie XML-basierte Templating mögen.
Als jemand, der neu bei der ganzen Sache ist, ist es schwer zu sagen, mit welcher Methode man am einfachsten anfangen kann. Vielleicht Jinja2.
2) SQL Alchemy et al. Ein ORM. Gut.
Ja.
3) Ein Renderer. Keine Ahnung.
Ein Renderer ist eine Konfigurationsoption für die Pyramidenansicht, die Pyramid mitteilt, dass, wenn Ihre Ansicht ein dict zurückgibt, sie an den gegebenen "Renderer" übergeben werden soll. Renderer sind so eingestellt, dass sie mit Erweiterungsnamen arbeiten, und Pyramid kommt mit mehreren eingebauten: Ссылка
Kurz gesagt, die Renderer-Option betrachtet nur den Namen, an den Sie übergeben werden, und findet eine Template-Engine, die der Erweiterung entspricht (.mak, .pt, 'json', 'string', .etc) und das Dict rendert Ergebnisse damit.
In vielen Frameworks geben Sie keinen Renderer als Konfiguration an, sondern haben etwas Code in der Ansicht, der ungefähr so aussieht:
%Vor%In Pyramid könntest du das gleiche tun mit:
%Vor%Es gibt mehrere Gründe, warum Letzteres nützlich ist:
Wenn es vollständig konfiguriert ist, können Sie den Renderer überschreiben, ohne die Logik des Ansichtscodes ändern zu müssen.
Sie können mehrere Konfigurationen hinzufügen, die den Renderer basierend auf anderen Bedingungen ändern.
Betrachten Sie dieses Beispiel, das den Renderer basierend darauf ändert, ob die HTTP-Anfrage ein XHR ist (AJAX-Anfrage, die ein JSON-formatiertes Ergebnis haben möchte, statt einer allgemeinen HTTP-Anfrage, die HTML von der Template-Engine ausspucken möchte).
%Vor%4) JS-Bibliotheken: JQuery et al. Keine Ahnung Was nützen diese außer dem Hinzufügen? hübsche Effekte. Wie wirkt das zusammen? mit dem Templating-Motor? Wie geht es? das interagiert mit dem Ganzen Rahmen? Kann ich Code für jQuery schreiben? in der Pyramide, oder schreibe ich JS getrennt, schließe meine JS Akte an meine an Vorlage oder ...?
JS-Bibliotheken erleichtern das Schreiben von Javascript. Sie interagieren im Browser mit dem DOM und haben keine Interaktion mit Pyramid, nachdem sie HTTP-Anforderungen an Ihre Webanwendung gesendet haben, für die möglicherweise JSON-formatierte Ergebnisse gewünscht werden.
Zunächst würde ich vorschlagen, Javascript vollständig zu ignorieren, bis Sie mit HTML, der DOM-Struktur und einer Website, die nur mit HTML, CSS und der Web-Anwendung funktioniert, vertrauter sind.
5) Form Templating Bibliotheken (formish, formalchemy et al) Wie hängen diese zusammen? zum großen Bild? Wo stecken sie an? in?
Ich würde sehr empfehlen, diese vollständig zu ignorieren und grundlegende HTML-Formularelemente zu schreiben. Sie sind neu im gesamten Web-Stack und es besteht keine Notwendigkeit, direkt zu den fortgeschrittensten Aspekten der Web-Entwicklung zu springen, ohne sich zuerst mit den Grundlagen vertraut zu machen.
Was Sie nach dem Schreiben von Basisformularen benötigen, ist eine Formularvalidierungsbibliothek, die es einfacher macht zu überprüfen, ob das Formular, das übergeben wurde, gültige Parameter enthält. Zurück in den alten Tagen von PHP, würden Menschen Hunderte von Zeilen von if / else-Anweisungen schreiben, die durch Formulare gingen (einige tun es immer noch! Ack!).
Heutzutage verwenden wir Formularvalidierungsbibliotheken, die es einfach machen, die gültigen Parameter für ein Formular zu deklarieren. Ich würde zunächst FormEncode vorschlagen, da es recht einfach ist, nur zur Validierung zu verwenden. Für Pyramid ist der einfachste Weg, um mit FormEncode loszulegen, wahrscheinlich pyramid_simpleform: Ссылка
Ignorieren Sie jetzt den Formular-Rendering-Teil und schreiben Sie die HTML-Formularelemente selbst in die Vorlage und verwenden Sie pyramid_simpleform nur für die einfache FormEncode-Integration.
Kurz gesagt, beginnen Sie damit, dass Sie nur HTML-Seiten mit Links anzeigen, die Ansichtsfunktionen und Vorlagen verwenden (und URL-Versand verwenden, was einfacher zu verstehen ist als Traversieren für Anfänger). Fügen Sie dann Formulare, ihren HTML-Code und ihre Validierung hinzu und fügen Sie CSS hinzu, um mit dem Styling zu beginnen.
Als nächstes können Sie mit ein wenig Javascript mit jQuery beginnen, um Dinge auf der Seite zu bewegen, und sich mit AJAX über die Webapplikation austauschen, um mehr Daten zu erhalten. Greife einfach nicht zu viel auf einmal an, und es sollte einfacher sein, zu sehen, wie sie zusammenpassen.
3) Ein Renderer. Keine Ahnung.
Im Allgemeinen nimmt ein Renderer Ihre Daten / Modelle und konvertiert sie in etwas, das der Client möchte. Wenn der Client nur ein Browser ist, wird der Renderer normalerweise Ihre Daten durch eine Vorlage mischen, um HTML zu erzeugen. Wenn der Client ein JavaScript-Code oder eine Nicht-Browser-Anwendung ist (eine Desktop-Anwendung, ein anderer Server, der Ihre Daten verwendet, ...), würde der Renderer normalerweise JSON (oder möglicherweise XML) erzeugen. Sie können sich das als Serialisierungs- oder Marshalling-System vorstellen.
4) JS-Bibliotheken:
Dies ist, was Sie verwenden, um die Benutzeroberfläche zu programmieren. Die Benutzeroberfläche kann nur einige schöne Effekte sein, die auf HTML gesetzt werden, aber es könnte viel mehr sein. Google Docs zum Beispiel ist JavaScript und ein bisschen mehr als hübsche Effekte; Cloud9 IDE wäre ein weiteres Beispiel voller Anwendung mit JavaScript (dank Raynos für ein anderes Beispiel) gebaut.
5) Formularbeschreibungsbibliotheken
Sie können sich diese als (mehr oder weniger) Makrosysteme für die Template-Engine vorstellen. Wenn Sie ein Datenschema haben, können Sie mit diesen Dingen Template-Chunks generieren und automatisch die serverseitige Verarbeitung der entsprechenden Rückgabedaten übernehmen.
Irgendwelche anderen wichtigen Komponenten, die ich vermisse?
Sie können sich den modernen Web-Stack als traditionelles Client-Server-System vorstellen. Das wird wahrscheinlich einige Leute verärgern, aber es gibt nichts radikal Neues außer vielleicht die Skala. Der Client ist mit HTML und CSS für das Layout und JavaScript (möglicherweise mit einem Toolkit) für die Funktionalität und Augenweide gebaut. Der Server ist ein Webserver irgendeiner Art. Die Kommunikation zwischen Client und Server erfolgt normalerweise in einer Kombination von JSON und HTML über HTTP. Sie können sich an Web-1.0 denken (mag Gott meine Marketing-Talk-Terminologie verzeihen) als dummes Terminal der alten Schule, wo Web-2.0 mehr wie ein X-Terminal mit einigen Gehirnen auf dem Client ist.
Tags und Links python django javascript ajax pyramid