@ms4py: Zeile 5 von `wikipage()` könnte Probleme haben wenn `page_name` etwas ausserhalb von ASCII enthält, oder kommt `bottle.redirect()` damit klar?
Was wird in Anhang A gezeigt? Die Struktur von erm2py geparst? Das was erm2py parst und so im Speicher hält? Das Ergebnis von erm2py? Da wären IMHO ein paar mehr Worte als die Überschrift schön.
Bericht über Python Web Development
Ich würde Django und Bottle mit großem Anfangsbuchstaben schreiben. Der Trennstrich unter 1.2 bei pa-ge ist weder schön, noch grammatikalisch korrektes Englisch. Und wenn wir schon in dem Abschnitt sind: Es heißt Modelling (vgl. String Formatting). Auch würde ich persönlich weniger Anglizismen benutzen - Deploy -> Entwicklung, Use Cases -> Anwendungsfälle, usw. Zudem stolpere ich über deine Relativierungen, die du an mehreren Stellen machst. Dabei redest du dir irgendwie den ganzen Text weich. Entweder du begründest sie oder du lässt sie ganz weg, aber nicht: "Ich binde experimentelle Software ein, auch wenn man das normalerweise nicht tun sollte." Naja, mag sein, dass ich etwas streng bin und deinem Dozenten/Lehrer das alles relativ egal ist. 
Das dt. Wort "Page" ist so korrekt getrenntsnafu hat geschrieben:Ich würde Django und Bottle mit großem Anfangsbuchstaben schreiben. Der Trennstrich unter 1.2 bei pa-ge ist weder schön, noch grammatikalisch korrektes Englisch. Und wenn wir schon in dem Abschnitt sind: Es heißt Modelling (vgl. String Formatting).
LaTeX macht das automatisch, und deutsch ist eben eingestellt. Danke für den Hinweis, werde das korrigieren.
Deploy beziehe ich auf das Ausliefern der Applikation mit einem Server. Wikipedia nennt das "Softwareverteilung". Hört sich IMO etwas seltsam an. Aber da gehe ich trotzdem noch einmal darüber. (Wobei mein Prof da vermutlich kein Problem damit hat.)snafu hat geschrieben:Auch würde ich persönlich weniger Anglizismen benutzen - Deploy -> Entwicklung, Use Cases -> Anwendungsfälle, usw.
Ich habe kein Problem mit strenger Kritiksnafu hat geschrieben:Zudem stolpere ich über deine Relativierungen, die du an mehreren Stellen machst. Dabei redest du dir irgendwie den ganzen Text weich. Entweder du begründest sie oder du lässt sie ganz weg, aber nicht: "Ich binde experimentelle Software ein, auch wenn man das normalerweise nicht tun sollte." Naja, mag sein, dass ich etwas streng bin und deinem Dozenten/Lehrer das alles relativ egal ist.
Welche Stellen kommen noch so schwammig rüber?@BlackJack:
Danke. Werde ich korrigieren.
„Lieber von den Richtigen kritisiert als von den Falschen gelobt werden.“
Gerhard Kocher
http://ms4py.org/
Gerhard Kocher
http://ms4py.org/
Hier Teil 2 über WSGI und Frameworks:
http://ms4py.org/document2.pdf
Wäre schön, wenn jemand das Dokument bis morgen Abend durchschauen könnte. (Da ist Abgabe.)
Selbstverständlich sind letztendlich beide Teile in einem Bericht und ich stelle diesen dann auch zur Verfügung.
http://ms4py.org/document2.pdf
Wäre schön, wenn jemand das Dokument bis morgen Abend durchschauen könnte. (Da ist Abgabe.)
Selbstverständlich sind letztendlich beide Teile in einem Bericht und ich stelle diesen dann auch zur Verfügung.
„Lieber von den Richtigen kritisiert als von den Falschen gelobt werden.“
Gerhard Kocher
http://ms4py.org/
Gerhard Kocher
http://ms4py.org/
-
BlackJack
@ms4py: Beim "Hallo Welt"-Beispiel als Klasse steht dass es etwas komplexer ist, aber die Vorteile der Objektorientierung bietet. Da sollte man IMHO näher drauf eingehen was die Vorteile sind. Ich meine jetzt ausser das Java-Jünger glücklich sind, wenn sie etwas in eine Klasse stecken können.
`Middleware` würde ich entweder an der Stelle erklären wo der Begriff das erste mal vorkommt, oder dort auf den Abschnitt mit dem Titel verweisen. Bei der Abbildung gibt's IMHO bessere Möglichkeiten. In der Django-Doku gibt's irgendwo ein Bild wo statt des Servers links "Request" und rechts "Response" steht und ein Pfeil durch die "Zwiebeldarstellung" der Schichten von einem zum anderen läuft. Das macht deutlicher das es sich aus Sicht der Anwendung eigentlich um "aroundware" handelt, also die Daten beim Eingang wie auch beim Ausgang durch die Middleware laufen. Wenn man mehr als eine Middleware in dem Bild zeigt wird ausserdem deutlich wie die Reihenfolge der Verarbeitung ist, wenn man mehrere Middlewares kombiniert.
Beim `Capitalizer` sehe ich übrigens den Sinn einer Klasse nicht. Den hätte man Problemlos als Funktion implementieren können.
Der erste Absatz zu CherryPy sollte dringend überarbeitet werden. Das liest sich als wenn man unter Windows keine Webserver laufen lassen kann.
Es werden eine Menge "Füllworte" verwendet. Geh da noch mal durch und schau ob man "Eigentlich", "selbstverständlich", "typisch", "auch" usw. wirklich an jeder Stelle braucht, oder ob der Sinn der Sätze ohne diese "schwammigen" Worte nicht genauso erhalten bleibt. Zum Beispiel "Selbstverständlich antwortet eine Webapplikation auch auf Anfragen…". Ist das selbstverständlich? Wenn nein warum nicht, wenn ja, muss das Wort da wirklich stehen? Und warum "auch"? Was tut sie sonst noch? Ist das nicht eine der Hauptaufgaben? In nächsten Absatz mit den Requests und Responses bist Du IMHO ungenau mit Klassen und Exemplaren davon. Das Rahmenwerk stellt Klassen zur Verfügung, die Applikation *verarbeitet* die aber nicht.
Abschnitt `Scaffolding`: Vielleicht besser "Testdatenbestände" statt "Testbestände".
Ich weiss das ist jetzt nicht inhaltlich, aber warum sind `URL-Routing` und `Template-Engine` im `Bottle`-Abschnitt fett gesetzt? Damit stechen die unheimlich ins Auge und fallen aus dem Rahmen.
Und noch eine technische Frage zu `erm2py`/`elixir`: Warum wird die `__str__()`-Methode überschrieben und nicht die `__repr__()? Das was da zurückgegeben wird ist IMHO eher was für Programmierer als für Endanwender!? Und ist das so viel besser als die normale `__repr__()` auf die `__str__()` ja zurückfällt wenn's nicht überschrieben wurde!? Also muss man da überhaupt was überschreiben? Was ist der Vorteil von *dieser* Lösung?
`Middleware` würde ich entweder an der Stelle erklären wo der Begriff das erste mal vorkommt, oder dort auf den Abschnitt mit dem Titel verweisen. Bei der Abbildung gibt's IMHO bessere Möglichkeiten. In der Django-Doku gibt's irgendwo ein Bild wo statt des Servers links "Request" und rechts "Response" steht und ein Pfeil durch die "Zwiebeldarstellung" der Schichten von einem zum anderen läuft. Das macht deutlicher das es sich aus Sicht der Anwendung eigentlich um "aroundware" handelt, also die Daten beim Eingang wie auch beim Ausgang durch die Middleware laufen. Wenn man mehr als eine Middleware in dem Bild zeigt wird ausserdem deutlich wie die Reihenfolge der Verarbeitung ist, wenn man mehrere Middlewares kombiniert.
Beim `Capitalizer` sehe ich übrigens den Sinn einer Klasse nicht. Den hätte man Problemlos als Funktion implementieren können.
Der erste Absatz zu CherryPy sollte dringend überarbeitet werden. Das liest sich als wenn man unter Windows keine Webserver laufen lassen kann.
Es werden eine Menge "Füllworte" verwendet. Geh da noch mal durch und schau ob man "Eigentlich", "selbstverständlich", "typisch", "auch" usw. wirklich an jeder Stelle braucht, oder ob der Sinn der Sätze ohne diese "schwammigen" Worte nicht genauso erhalten bleibt. Zum Beispiel "Selbstverständlich antwortet eine Webapplikation auch auf Anfragen…". Ist das selbstverständlich? Wenn nein warum nicht, wenn ja, muss das Wort da wirklich stehen? Und warum "auch"? Was tut sie sonst noch? Ist das nicht eine der Hauptaufgaben? In nächsten Absatz mit den Requests und Responses bist Du IMHO ungenau mit Klassen und Exemplaren davon. Das Rahmenwerk stellt Klassen zur Verfügung, die Applikation *verarbeitet* die aber nicht.
Abschnitt `Scaffolding`: Vielleicht besser "Testdatenbestände" statt "Testbestände".
Ich weiss das ist jetzt nicht inhaltlich, aber warum sind `URL-Routing` und `Template-Engine` im `Bottle`-Abschnitt fett gesetzt? Damit stechen die unheimlich ins Auge und fallen aus dem Rahmen.
Und noch eine technische Frage zu `erm2py`/`elixir`: Warum wird die `__str__()`-Methode überschrieben und nicht die `__repr__()? Das was da zurückgegeben wird ist IMHO eher was für Programmierer als für Endanwender!? Und ist das so viel besser als die normale `__repr__()` auf die `__str__()` ja zurückfällt wenn's nicht überschrieben wurde!? Also muss man da überhaupt was überschreiben? Was ist der Vorteil von *dieser* Lösung?
Noch ein bißchen was kleinkariertes zum Inhaltsverzeichnis: Mit den großen Anfangsbuchstaben meinte ich nicht, dass du Bottle & Co nicht mehr kursiv schreiben sollst. So etwas finde ich für Eigennamen eigentlich ganz schön und teilweise machst du es ja auch noch, was das Ganze noch unregelmäßiger rüberkommen lässt. Und warum wird "Web Development" eigentlich im Gegensatz zu "Web-Framework" auseinander geschrieben? 
Zu 1.1.3: In "Deren Signatur wurde bereits ausführlich besprochen" steckt IMHO auch so ein überflüssiges Füllwort. Denn ob deine Erläuterungen wirklich so ausführlich waren, liegt sicher im Auge des Betrachters. Mit einem Augenzwinkern möchte ich noch anmerken, dass echte Hardcore-Wissenschaftler die Dinge nicht erklären, sondern es laut eigener Aussage lediglich *versuchen* (zumindest kenne ich das von den Geisteswissenschaftlern so).
Zu 1.1.3: In "Deren Signatur wurde bereits ausführlich besprochen" steckt IMHO auch so ein überflüssiges Füllwort. Denn ob deine Erläuterungen wirklich so ausführlich waren, liegt sicher im Auge des Betrachters. Mit einem Augenzwinkern möchte ich noch anmerken, dass echte Hardcore-Wissenschaftler die Dinge nicht erklären, sondern es laut eigener Aussage lediglich *versuchen* (zumindest kenne ich das von den Geisteswissenschaftlern so).
Vielen Dank für die Kritik. Noch ein paar konkrete Stellen zu dem "Füllwort-Problem" wäre super!
Das mit dem `__str__` ist mir bekannt, hätte ich längst mal beseitigen sollen
Das mit dem `__str__` ist mir bekannt, hätte ich längst mal beseitigen sollen
„Lieber von den Richtigen kritisiert als von den Falschen gelobt werden.“
Gerhard Kocher
http://ms4py.org/
Gerhard Kocher
http://ms4py.org/
wg. Füllworte
1.1.2 Listing 2
Edit:
Etwas zu 1.2.3: Du verweist mit dem apt-get Beispiel implizit auf Ubuntu, deine weiteren Konfigurationsschnippsel passen dann aber nicht mehr zu Ubuntu. Evt. wäre es besser,
Wg. Ubuntu:
Zu Listing 8:
Insgesamt würde ich die Referenz auf Ubuntu entfernen und dann ist der Rest ja auch OK. Wobei ich bei mod-wsgi den Daemon-Modus wegen der Performanz entgegen dem "embedded mode" noch hervorheben würde. Das tust du zwar indirekt, indem du die WSGIDaemonProcess Direktive verwendest, aber nicht weiter darauf eingehst.
Bitte diese Korinthenkackerei nicht falsch verstehen, aber du hattest gefragt
1.1.2 Listing 2
Es ist ja nicht nicht im eigentlichen Sinne die Komplexität, die die Vorteile der Objektorientierung bietet. Ich würde das so schreiben:Listing 2 ist etwas komplexer, bietet aber dadurch die Vorteile der Objektorientierung.
Wenn mir noch was auffällt, schreib ich's hier rein ...Listing 2 ist komplexer, bietet aber die Vorteile der Objektorientierung.
Edit:
Etwas zu 1.2.3: Du verweist mit dem apt-get Beispiel implizit auf Ubuntu, deine weiteren Konfigurationsschnippsel passen dann aber nicht mehr zu Ubuntu. Evt. wäre es besser,
alsUnter
Ubuntu lasst es sich mit apt-get installieren.
# apt-get install libapache2-mod-wsgi
zu schreibenInstallation mittels apt-get ...
Wg. Ubuntu:
Dazu nimmt man bei Ubuntu die site-configs unter sites-available, die httpd.conf ist standardmässig leer.Dazu kann entweder die globale
httpd.conf oder ...
Zu Listing 8:
www-data ist der Standardbenutzer für den Apachen unter Ubuntu und deshalb ist der Eintrag hier nicht notwendig.user=www-data group=www-data
Insgesamt würde ich die Referenz auf Ubuntu entfernen und dann ist der Rest ja auch OK. Wobei ich bei mod-wsgi den Daemon-Modus wegen der Performanz entgegen dem "embedded mode" noch hervorheben würde. Das tust du zwar indirekt, indem du die WSGIDaemonProcess Direktive verwendest, aber nicht weiter darauf eingehst.
Bitte diese Korinthenkackerei nicht falsch verstehen, aber du hattest gefragt
2.1.3 Datenbankzugriff finde ich insgesamt nicht so gelungen. Sinn eines Dal ist es meines Wissens nach Implementierungsdetails der Datenbankschnittstelle vor dem Programmierer zu verbergen und nicht, mal eben unter Haube die Datenbank zu wechseln, so wie du es schreibst.
klingt meiner Meinung nach (schwamminger) unbeleger Behauptung, besser wäre es in meinen Augen, da konkreter zu werden. Und zwar entweder bei den unterschiedlichen ORMs (gibt's da ausser SqlAlchemy und Django noch was?) und dann auf die Kopplungsmöglichkeiten hinzuweisen oder konkret eine Tabelle oder sowas als Beleg dazubringen. Im zweiten Absatz fehlt mir auch noch irgendwie der Hinweis, was die Problematik bei der Abbildung der tab. Daten auf Objekte darstellt, Stichwort Impedance MismatchViele Web-Frameworks bieten eine einheitliche Schnittstelle zu den verschiedenen Datenbanksystemen
„Lieber von den Richtigen kritisiert als von den Falschen gelobt werden.“
Gerhard Kocher
http://ms4py.org/
Gerhard Kocher
http://ms4py.org/