Hallo Liste, ich bin in die Verlegenheit gekommen für eine Applikation ein web-frontend schreiben zu müssen. Da ich das Rad nicht unbeding noch einmal erfinden will, suche ich ein geeignetes Web-Framework für Python. Da ich Web-Framework-Materie keine Ahnung habe möchte ich euch um Verschläge bitten, welches Web-Frontend wohl das geeignetste ist. Ich habe schon einiges gefunden (Zope, Django, TurboGear, ...) aber welches das Richtige ist (oder das Falsche) hat sich nicht wirklich herrauskristallisiert. Was würdet ihr einsetzten ? -- cu Roland M. Kruggel mailto:rk.liste@bbf7.de http:www.bbf7.de System: Intel, Debian etch, 2.6.21, xfce4, KDE 3.5 ------------ Zufallszitat Die meisten Frauen nehmen nur beim Telefonieren ab.
ich bin in die Verlegenheit gekommen für eine Applikation ein web-frontend schreiben zu müssen.
gute frage, koennte man mal ausfuehrlich diskutieren!
um Verschläge bitten, welches Web-Frontend wohl das geeignetste ist.
Leider verrätst Du nichts über die Applikation, sonst wuesste man sicher schneller Rat. Persoenlich liebaeugele ich derzeit fuer eine reine Web-Geschichte mit einem Wechsel von Zope zu Django, im Wissen, dass TurboGear oder Twistedmatrix die besseren Lösungen wären, aber dafür reicht's halt derzeit noch nicht... Also man muesste schon wissen, was das fuer eine Applikation ist, Datenbank, XML, API? Dann kann der eine oder andere hier sicher einen Tipp geben. Kai
Am Montag, 22. Oktober 2007 schrieb Kai Festersen:
ich bin in die Verlegenheit gekommen für eine Applikation ein web-frontend schreiben zu müssen.
gute frage, koennte man mal ausfuehrlich diskutieren!
Oh ja :)
um Verschläge bitten, welches Web-Frontend wohl das geeignetste ist.
Leider verrätst Du nichts über die Applikation, sonst wuesste man sicher schneller Rat.
Es handelt sich um eine Mail-Applikation. Mit der an verschiedene adressen diverse Texte versand werden. (Ähnlich Mailverteiler, aber wirklich nur ähnlich) Momentan wird das Programm über ein email-interface gesteuert. (ähnlich dem von mailman, etc.) D.h. ich schicken dem Programm eine email mit bestimmten Texten und Befehlen. Der Rest wird dann von dem Programm erledigt. Es funktioniert auch alles gut, nur kommen viele User nicht mit dem Mail-Interface zurecht. Die hätten halt lieber was zum anklicken. -- Nun gut. Es muss also ein Web-Interface her.
Persoenlich liebaeugele ich derzeit fuer eine reine Web-Geschichte mit einem Wechsel von Zope zu Django, im Wissen, dass TurboGear oder Twistedmatrix die besseren Lösungen wären, aber dafür reicht's halt derzeit noch nicht...
Also man muesste schon wissen, was das fuer eine Applikation ist, Datenbank, XML, API? Dann kann der eine oder andere hier sicher einen Tipp geben.
Datenbank - Ja, XML - Nein, API - Nein. Ich benötige ein Framework mit dem ich Textfelder, Eingabefelder, Buttons etc. einfach definieren kann. Eswerden nicht viele html-Seiten erzeugt. Es wird ja 'nur' ein Applikation-Interface. -- cu Roland M. Kruggel mailto:rk.liste@bbf7.de http:www.bbf7.de System: Intel, Debian etch, 2.6.21, xfce4, KDE 3.5 ------------ Zufallszitat Droht der Bauer mit der Rute, zieht die Stute eine Schnute.
guten morgen, so ungern ich dem hochgeschätzten Andreas Jung widerspreche, aber das klingt mir auch nach einem Fall für Django, damit würde man am schnellsten Ergebnisse erzielen. grok.zope.org scheint mir ein überzeugendes Projekt, "Zope für Neandertaler", aber... Du hast da eine enorme Lernkurve, denn Grok, so will mir scheinen, haben Leute erfunden, die der Meinung sind, dass Zope mittlerweile zu kompliziert und Ein-/Umsteigerunfreundlichl ist und deswegen die Lernkurve abflachen wollen. Aber da setzt Du Dich quasi in einen Mercedes CLK, in den ein Smart eingebaut wurde, um den bedienen zu können. Irgendwann brauchst Du aber den Mercedes... Mit Django ist sowas, wie Du da planst (soweit verstanden) vermutlich in zwei Tagen realisiert, wenn Du die Daten in einer Datenbank vorhalten kannst/willst (MySQL, Postgres, SQLite). Twistedmatrix ginge sicher auch, die haben einen Mailserver dabei (twisted-mail), aber auch ... Lernkurve... Kai
Hallo, On Tue, 23 Oct 2007 08:06:31 +0200 Kai Festersen <kai.festersen@gmx.de> wrote:
so ungern ich dem hochgeschätzten Andreas Jung widerspreche, aber das klingt mir auch nach einem Fall für Django, damit würde man am schnellsten Ergebnisse erzielen. Ich habe in letzter Zeit estwas mit Pylons versucht, aber das war mir irgendwie überkompliziert, zumindest wenn man von Django kommt. Mein letztes Projekt habe ich daher mit dem Nicht-Framework "Werkzeug"[1] gemacht, einer Sammlung WSGI-Werkzeuge die doch ziemlich brauchbar sind.
Ich habe mir in kürzester Zeit eine Django-ähnliche Umgebung gebastelt und habe nun ein vergleichsweise kleines und überschaubares Toolkit, welches mir völlige Freiheit lässt welche Komponenten ich nutzen will und welche nicht. Was kleine Fast-Frameworks angeht, würde ich sagen, dass Werkzeug momentan schlichtweg die beste Wahl ist. Für alle die es nicht kennen: Werkzeug ist der quasi-Nachfolger von Colubrid, ist ziemlich akzeptabel dokumentiert und recht simpel zu überblicken. Noch dazu gibt es im IRC schnell Hilfe :D Vielleicht mache ich wieder was mit Pylons, aber hisher fahre ich mit Werkzeug einfach zu gut. grüße, Marek [1] http://werkzeug.pocoo.org/
Es handelt sich um eine Mail-Applikation. Mit der an verschiedene adressen diverse Texte versand werden. (Ähnlich Mailverteiler, aber wirklich nur ähnlich)
Momentan wird das Programm über ein email-interface gesteuert. (ähnlich dem von mailman, etc.) D.h. ich schicken dem Programm eine email mit bestimmten Texten und Befehlen. Der Rest wird dann von dem Programm erledigt.
Es funktioniert auch alles gut, nur kommen viele User nicht mit dem Mail-Interface zurecht. Die hätten halt lieber was zum anklicken. -- Nun gut. Es muss also ein Web-Interface her.
Persoenlich liebaeugele ich derzeit fuer eine reine Web-Geschichte mit einem Wechsel von Zope zu Django, im Wissen, dass TurboGear oder Twistedmatrix die besseren Lösungen wären, aber dafür reicht's halt derzeit noch nicht...
Also man muesste schon wissen, was das fuer eine Applikation ist, Datenbank, XML, API? Dann kann der eine oder andere hier sicher einen Tipp geben.
Datenbank - Ja, XML - Nein, API - Nein. Ich benötige ein Framework mit dem ich Textfelder, Eingabefelder, Buttons etc. einfach definieren kann. Eswerden nicht viele html-Seiten erzeugt. Es wird ja 'nur' ein Applikation-Interface.
[Disclaimer: ich bin TurboGears-commiter] Ich habe das letzte mal mit Django vor etwa 2 Jahren "gespielt", eine ernsthafte Anwendung darin habe ich nicht entwickelt. In TG eine AJAX-lastige Museumsanwendung. Und neulich gab's mal in der C-Base zu Berlin ein Treffen mit 2 Django-apologeten. Ich denke geeignet sind beide (und sicher auch ZOPE). Was mir aber persoenlich an TG am besten gefaellt ist das widget-prinzip. Du kannst hochdeklarativ Formulare zusammenbauen, die dann dargestellt & validiert werden. Ich kann mich nicht erinnern, das das mit Django so einfach war, geschweige denn mit Zope (wobei beide eventuell Erweiterungen haben die das erlauben). Bei Django gab's halt das Admin-interface. Gut, wenn man es gebrauchen kann wie's ist. Aber wenn man etwas eigenes braucht, baut man alles selbst. In TG gibt's dafuer den Catwalk, aber besonders intensiv genutzt habe ich den nie. Klare Schwachstellen von TG sind aber - maessige Doku - momentan Versionnen 1.0.x, 1.1 & 2.0 in der Entwicklung. Wobei letztere auf Pylons aufsetzen wird. Man muss sich also entscheiden, ob man auf bewaehrtes (1.0) oder kommendes setzt. Wobei die Unterschiede nicht zu dramatisch sein sollten. Ich habe mal aus Spass an der Freude innerhalb von 7min eine Applikation entwickelt, die create/update/delete beherrschte. Aber eben mittels eigener (und damit natuerlich hochgradig anpassbarer) Formular-Widgets, nichts generiertes. MfG Diez
Diez B. Roggisch schrieb:
Ich habe das letzte mal mit Django vor etwa 2 Jahren "gespielt", eine ernsthafte Anwendung darin habe ich nicht entwickelt. In TG eine AJAX-lastige Museumsanwendung.
Was mir aber persoenlich an TG am besten gefaellt ist das widget-prinzip. Du kannst hochdeklarativ Formulare zusammenbauen, die dann dargestellt & validiert werden. Ich kann mich nicht erinnern, das das mit Django so einfach war, geschweige denn mit Zope (wobei beide eventuell Erweiterungen haben die das erlauben).
Ist denke das ist das selbe wie newforms: http://www.djangoproject.com/documentation/newforms/ Also ich nutzte auch django und kann es nur empfehlen. -- Mfg. Jens Diemer ---- A django powered CMS: http://www.pylucid.org
On Tuesday 23 October 2007 13:02:06 Jens Diemer wrote:
Diez B. Roggisch schrieb:
Ich habe das letzte mal mit Django vor etwa 2 Jahren "gespielt", eine ernsthafte Anwendung darin habe ich nicht entwickelt. In TG eine AJAX-lastige Museumsanwendung.
Was mir aber persoenlich an TG am besten gefaellt ist das widget-prinzip. Du kannst hochdeklarativ Formulare zusammenbauen, die dann dargestellt & validiert werden. Ich kann mich nicht erinnern, das das mit Django so einfach war, geschweige denn mit Zope (wobei beide eventuell Erweiterungen haben die das erlauben).
Ist denke das ist das selbe wie newforms: http://www.djangoproject.com/documentation/newforms/
Das kommt dem nahe, ist aber nicht so flexibel. Widgets in TG sind generell dazu gedach & geeignet, CSS, JS + HTML zu funktionalen Einheiten zu buendeln. Wie ich an der Doku sehe, hat man die Wahl entweder zu nehmen was es gibt, oder doch relativ umstaendlich die Dinger in ein Template zu betten. In TG gibt's nen sinnvolles Standardtemplate, das dann aber sehr einfach umdefiniert werden kann. Doch letztlich sind die beiden sich nahe, kein Zweifel. Diez
Hallo, On Tue, 23 Oct 2007 13:50:11 +0200 "Diez B. Roggisch" <deets@web.de> wrote:
Ist denke das ist das selbe wie newforms: http://www.djangoproject.com/documentation/newforms/
Das kommt dem nahe, ist aber nicht so flexibel. Widgets in TG sind generell dazu gedach & geeignet, CSS, JS + HTML zu funktionalen Einheiten zu buendeln. Wie ich an der Doku sehe, hat man die Wahl entweder zu nehmen was es gibt, oder doch relativ umstaendlich die Dinger in ein Template zu betten. In TG gibt's nen sinnvolles Standardtemplate, das dann aber sehr einfach umdefiniert werden kann.
Doch letztlich sind die beiden sich nahe, kein Zweifel.
Ist das in TG nicht ToscaWidgets? Die sind ja standalone, also könnte man sie theoretisch auch in Django nutzen. Habe ich aber bisher nicht gemacht, nutze selbst die newforms. grüße, Marek
Das kommt dem nahe, ist aber nicht so flexibel. Widgets in TG sind generell dazu gedach & geeignet, CSS, JS + HTML zu funktionalen Einheiten zu buendeln. Wie ich an der Doku sehe, hat man die Wahl entweder zu nehmen was es gibt, oder doch relativ umstaendlich die Dinger in ein Template zu betten. In TG gibt's nen sinnvolles Standardtemplate, das dann aber sehr einfach umdefiniert werden kann.
Doch letztlich sind die beiden sich nahe, kein Zweifel.
Ist das in TG nicht ToscaWidgets? Die sind ja standalone, also könnte man sie theoretisch auch in Django nutzen. Habe ich aber bisher nicht gemacht, nutze selbst die newforms.
Die gibt's auch, ja. Und es kann auch gut sein, das die recht gut alleine arbeiten. Aber ein bisschen Rahmenwerk um zB die einzubindenden resourcen in die Seite zu rendern und so braucht man schon. Insofern ist es ein bisschen mehr als plug&play. Aber sollte einfach genug sein. Ich sehe das auch nicht als "schwieriges" feature an - aber es ist nett & gut & funktioniert, und ich arbeite sehr effizient damit. Diez
[...]
Ich denke geeignet sind beide (und sicher auch ZOPE).
Was mir aber persoenlich an TG am besten gefaellt ist das widget-prinzip. Du kannst hochdeklarativ Formulare zusammenbauen, die dann dargestellt & validiert werden. Ich kann mich nicht erinnern, das das mit Django so einfach war, geschweige denn mit Zope (wobei beide eventuell Erweiterungen haben die das erlauben).
Ok. Was ich in den letzten 2 Tagen gelesen habe (ich habe alle hier vorgeschlagenen web-frameworks gelesen) tendiere ich momentan auch zu TurboGears. Ich glaube es ist das was für eine Web-Applikation am besten passt.
- maessige Doku
Ja, leider.
- momentan Versionnen 1.0.x, 1.1 & 2.0 in der Entwicklung. Wobei letztere auf Pylons aufsetzen wird. Man muss sich also entscheiden, ob man auf bewaehrtes (1.0) oder kommendes setzt. Wobei die Unterschiede nicht zu dramatisch sein sollten.
Ich glaube, damit kann ich leben.
Ich habe mal aus Spass an der Freude innerhalb von 7min eine Applikation entwickelt, die create/update/delete beherrschte. Aber eben mittels eigener (und damit natuerlich hochgradig anpassbarer) Formular-Widgets, nichts generiertes.
Oh. 7 Minuten. Könntest du mir die zur Verfügung stellen? Aus quellcode lässt sich immer am besten lernen. -- cu Roland M. Kruggel mailto:rk.liste@bbf7.de http:www.bbf7.de System: Intel, Debian etch, 2.6.21, xfce4, KDE 3.5 ------------ Zufallszitat Steuern sind ein erlaubter Fall von Raub. -- Thomas von Aquin
Oh. 7 Minuten. Könntest du mir die zur Verfügung stellen? Aus quellcode lässt sich immer am besten lernen.
Theoretisch ja, praktisch kA wo die ist. Aber wenn ich dazu komme (wir bereiten auch gerade release 1.0.4 vor + 1.1 kommt) dann baue ich nochmal was. dauert ja nicht so lange :) Diez
Hi,
Ok. Was ich in den letzten 2 Tagen gelesen habe (ich habe alle hier vorgeschlagenen web-frameworks gelesen) tendiere ich momentan auch zu TurboGears. Ich glaube es ist das was für eine Web-Applikation am besten passt. Was ich noch sehr unterhaltsam fand ist das Video "Better Web Application Framework" von Sean Kelly. Das ist zwar nicht unbedingt objektiv, aber nett gemacht.
http://video.google.com/videoplay?docid=6297126166376226181&q=web+application&pr=goog-sl Sven
Hallo Roland,
Ich habe schon einiges gefunden (Zope, Django, TurboGear, ...) aber welches das Richtige ist (oder das Falsche) hat sich nicht wirklich herrauskristallisiert. Was würdet ihr einsetzten ? Letztendlich ist das wohl Geschmackssache und Sache der Anforderungen. Ich setze Django bislang bei 2 kleinen Spass-Projekten ein, eines davon [1]. Ohne jetzt die Featureliste herunterzubeten, ich finde Django hat :
* Eine hervorragende Dokumentation * Eine komplett testbasierte Entwicklung, die neben Stabilität auch noch Dokumentation bietet. * Einen sehr angenehmen flexiblen ORM * Loose Coupling ist ein Prinzip, man kann problemlos alle Komponenten inkl. Template-System oder ORM austauschen. * Eine sehr aktive Entwicklung Leider gab es das letzte Mal als ich aktiv gesucht habe keine wirkliche Deutschsprachige Community, und man muss sich mit Google Groups anfreunden. Dort ist aber allerhand los. Ob es was für dich ist siehst du vielleicht auf [2] und [3]. Bei DjangoSites gibts auch ganze Webseiten mit Code. [1] http://www.fun-metal-bucket.de [2] http://www.djangosites.org/latest/ [3] http://www.djangosnippets.org/ </propaganda> :) Bye Sven
Hallo Ihr! Sven Broeckling wrote:
Leider gab es das letzte Mal als ich aktiv gesucht habe keine wirkliche Deutschsprachige Community, und man muss sich mit Google Groups anfreunden. Dort ist aber allerhand los.
Eine solche könnte man mal gründen, wäre so langsam an der Zeit, findet ihr nicht auch? Eine Google Group wäre schnell gegründet, wer wäre dabei? Falls das Publikum für Django zu klein wäre könnte man auch ein python-webframework-german - Gruppe gründen..? Natürlich auch ein anderes Medium statt einer Google Group wenn da die Akzeptanz größer wäre. Grüße Markus
Es existiert bereits eine Deutsche Python Google Gruppe: <http://groups.google.com/group/de.comp.lang.python/topics> Eine weitere Aufsplitterung sollte man vermeiden. Die existierenden Listen sind vollkommen ausreichend. Also -1 für den Vorschlag. -aj --On 23. Oktober 2007 09:12:53 +0200 Markus Majer <mm@mpathy.de> wrote:
Hallo Ihr!
Sven Broeckling wrote:
Leider gab es das letzte Mal als ich aktiv gesucht habe keine wirkliche Deutschsprachige Community, und man muss sich mit Google Groups anfreunden. Dort ist aber allerhand los.
Eine solche könnte man mal gründen, wäre so langsam an der Zeit, findet ihr nicht auch? Eine Google Group wäre schnell gegründet, wer wäre dabei?
Falls das Publikum für Django zu klein wäre könnte man auch ein python-webframework-german - Gruppe gründen..?
Natürlich auch ein anderes Medium statt einer Google Group wenn da die Akzeptanz größer wäre.
Grüße Markus
_______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de
* Andreas Jung <lists@andreas-jung.com> [071023 11:22]:
Es existiert bereits eine Deutsche Python Google Gruppe: WTF? Was soll denn bitteschön eine Google Gruppe sein? groups.google.com ist nur ein lausiges Web-nach-Usenet-Gateway mit dem dajanews-Archiv dahinter. "http://de.wikipedia.org/wiki/Usenet"
-- Whenever you find that you are on the side of the majority, it is time to reform. -- Mark Twain
--On 23. Oktober 2007 11:34:35 +0200 lumbricus@gmx.net wrote:
* Andreas Jung <lists@andreas-jung.com> [071023 11:22]:
Es existiert bereits eine Deutsche Python Google Gruppe: WTF? Was soll denn bitteschön eine Google Gruppe sein? groups.google.com ist nur ein lausiges Web-nach-Usenet-Gateway mit dem dajanews-Archiv dahinter. "http://de.wikipedia.org/wiki/Usenet"
und? :-) -aj
lumbricus@gmx.net:
* Andreas Jung <lists@andreas-jung.com> [071023 11:22]:
Es existiert bereits eine Deutsche Python Google Gruppe:
WTF? Was soll denn bitteschön eine Google Gruppe sein? groups.google.com ist nur ein lausiges Web-nach-Usenet-Gateway mit dem dajanews-Archiv dahinter.
Jein. Inzwischen kann man AFAIK auch "Google Groups" anlegen, die nie im Usenet landen. Beide Arten sind unter groups.google.com aber nicht unbedingt leicht unterscheidbar (evtl. am Namen oder so, aber es springt einem nicht sofort ins Auge). Ansonsten teile ich aber die Meinung. Google (und sowieso der ganze Webkram) ist Mist. de.comp.lang.python kann jeden Traffic gebrauchen und die Python-Webframeworks sind dort definitiv on-topic. Wenn nur slrn endlich in einer UTF-8-Umgebung funktionieren würde... J. -- I am worried that my dreams pale in comparison beside TV docu-soaps. [Agree] [Disagree] <http://www.slowlydownward.com/NODATA/data_enter2.html>
Jochen Schulz:
Ansonsten teile ich aber die Meinung. Google (und sowieso der ganze Webkram) ist Mist. de.comp.lang.python kann jeden Traffic gebrauchen und die Python-Webframeworks sind dort definitiv on-topic.
D'ouh. Mail-Followup-To lesen bildet. Hier wäre das alles natürlich genau so gut aufgehoben. :) J. -- I'm being paid to act weirdly. [Agree] [Disagree] <http://www.slowlydownward.com/NODATA/data_enter2.html>
Hallo, Am Dienstag, 23. Oktober 2007 09:12:53 schrieb Markus Majer:
Hallo Ihr!
Sven Broeckling wrote:
Leider gab es das letzte Mal als ich aktiv gesucht habe keine wirkliche Deutschsprachige Community, und man muss sich mit Google Groups anfreunden. Dort ist aber allerhand los.
Eine solche könnte man mal gründen, wäre so langsam an der Zeit, findet ihr nicht auch? Eine Google Group wäre schnell gegründet, wer wäre dabei?
Falls das Publikum für Django zu klein wäre könnte man auch ein python-webframework-german - Gruppe gründen..?
Natürlich auch ein anderes Medium statt einer Google Group wenn da die Akzeptanz größer wäre.
es gibt die mailingliste (diese hier) es gibt die Newsgroup de.comp.lang.python es gibt den wiki wiki.python.de Reicht das nicht? Warum noch mehr? Stephan
Grüße Markus
_______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de
Stephan Diehl schrieb:
es gibt die mailingliste (diese hier) es gibt die Newsgroup de.comp.lang.python es gibt den wiki wiki.python.de
Reicht das nicht? Warum noch mehr?
Und es gibt natürlich das deutsche python-forum.de Im Forum "Dynamische Webinhalte und Netzwerkprogrammierung" gibt es auch viele "django" Threads: http://www.python-forum.de/forum-3.html (Eine Suche nach "django" liefert 221 Treffer) Es gibt auch ein Thread zum Thema deutsche Community: http://www.python-forum.de/topic-11908.html Übrigens gibt es auch eine Wiki Seite "Web-Frameworks": http://wiki.python.de/Web-Frameworks -- Mfg. Jens Diemer ---- A django powered CMS: http://www.pylucid.org
Hallo, es ist schon wieder lange her, dass wir uns getroffen haben. Die naechste Gelegenheit ist am Mittwoch, den 31.10.2007 um 19:00 Uhr. Ort: newthinking store, Tucholskystr. 48, 10117 Berlin Dort ist ein Beamer vorhanden, d.h. jeder ist herzlich eingeladen, einen kleinen Vortrag zu halten. Noch haben wir kein Programm, aber das kann ja noch werden. Allem Anschein nach funktioniert unsere alte Mailingliste auf starship python wieder. Alle, die kommen wollen, sollten dort eingetragen sein. Adresse: http://starship.python.net/mailman/listinfo/python-berlin Ich bitte um kurze Rueckmeldung, wer kommt. Bis bald Stephan
Markus Majer schrieb:
Sven Broeckling wrote:
Leider gab es das letzte Mal als ich aktiv gesucht habe keine wirkliche Deutschsprachige Community, und man muss sich mit Google Groups anfreunden. Dort ist aber allerhand los.
Eine solche könnte man mal gründen, wäre so langsam an der Zeit, findet ihr nicht auch? Eine Google Group wäre schnell gegründet, wer wäre dabei?
Falls das Publikum für Django zu klein wäre könnte man auch ein python-webframework-german - Gruppe gründen..?
Natürlich auch ein anderes Medium statt einer Google Group wenn da die Akzeptanz größer wäre.
Bei meinem letzten Versuch, einer Google-Group beizutreten, bin ich an den kilometerlangen Geschäftsbedingungen von Google gescheitert, inklusive Anerkennung von Googles Patenten, Gutheißung der Werbung, Speicherung beliebiger Daten, usw. Insofern wäre ich wohl nicht der einzige, der nicht an sowas teilnehmen würde. Gruß, Stefan
dabei! im moment vorrangig für django, was mein interesse betraefe... kann also auch django-turbogears-twisted heissen... ;-) kai
Hallo Ihr! e
Sven Broeckling wrote:
Leider gab es das letzte Mal als ich aktiv gesucht habe keine wirkliche Deutschsprachige Community, und man muss sich mit Google Groups anfreunden. Dort ist aber allerhand los.
Eine solche könnte man mal gründen, wäre so langsam an der Zeit, findet ihr nicht auch? Eine Google Group wäre schnell gegründet, wer wäre dabei?
Falls das Publikum für Django zu klein wäre könnte man auch ein python-webframework-german - Gruppe gründen..?
Natürlich auch ein anderes Medium statt einer Google Group wenn da die Akzeptanz größer wäre.
Grüße Markus
_______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de
--On 22. Oktober 2007 22:53:37 +0200 "Roland M. Kruggel" <rk.liste@bbf7.de> wrote:
Hallo Liste,
ich bin in die Verlegenheit gekommen für eine Applikation ein web-frontend schreiben zu müssen.
Da ich das Rad nicht unbeding noch einmal erfinden will, suche ich ein geeignetes Web-Framework für Python. Da ich Web-Framework-Materie keine Ahnung habe möchte ich euch um Verschläge bitten, welches Web-Frontend wohl das geeignetste ist.
Ich habe schon einiges gefunden (Zope, Django, TurboGear, ...) aber welches das Richtige ist (oder das Falsche) hat sich nicht wirklich herrauskristallisiert.
Was würdet ihr einsetzten ?
Eindeutig GROK: <http://grok.zope.org/> GROK verbindet die Einfachheit von Python mit den mächtigen Komponenten, die uns die Zope Welt zur Verfügung stellt. Im Gegensatz zu Django oder TG ist es nicht RDBMS-basiert und verwendet die Zope-eigene ZODB, welche in vielen Kontexten die bessere Lösung ist. Relationale Datenbanken lassen sich natürlich ohne Probleme über die entsprechenden Python-Module einbinden. -aj
--On 22. Oktober 2007 22:53:37 +0200 "Roland M. Kruggel" <rk.liste@bbf7.de> wrote:
Hallo Liste,
ich bin in die Verlegenheit gekommen für eine Applikation ein web-frontend schreiben zu müssen.
Ich hatte auch nur auf das Originalposting geantwortet und da fehlte einfach Grok :-) Werbung muß sein :-) Gruß, Andreas
On Mon, 22 Oct 2007 22:53:37 +0200, "Roland M. Kruggel" <rk.liste@bbf7.de> wrote:
Hallo Liste,
ich bin in die Verlegenheit gekommen für eine Applikation ein web-frontend schreiben zu müssen.
Da ich das Rad nicht unbeding noch einmal erfinden will, suche ich ein geeignetes Web-Framework für Python. Da ich Web-Framework-Materie keine Ahnung habe möchte ich euch um Verschläge bitten, welches Web-Frontend wohl das geeignetste ist.
Soweit ich die Mails gelesen habe, wären für deinen Anwendungsfall alle Webframeworks ungefähr gleich gut geeignet.
Ich habe schon einiges gefunden (Zope, Django, TurboGear, ...) aber welches das Richtige ist (oder das Falsche) hat sich nicht wirklich herrauskristallisiert.
Was würdet ihr einsetzten ?
Pylons wurde noch nicht genannt, das ist seit einiger Zeit mein Favourite. Ich hab bisher nur eine kleine bis mittgelgröße Webapplikation in Python geschrieben (damals mit Snakelets), aber Spiel-Projekte hab ich im Laufe der Jahre schon mit Quixote, Snakelets, TurboGears und Pylons gemacht. Pylons ist aus den Ideen von Ruby und Rails und Mason (einem Perl-Framework) entstanden, nutzt den Python-Standard für Webapplikationen WSGI intensivst und ist dadurch sehr flexibel. Die Dokumentation ist mittlerweile meiner Meinung nach auch sehr gut. Die Flexibilität bringt ist auch nicht jedermann's Sache. Django/TurboGears haben starke Präferenzen was Datenbankschnittstelle, Templating usw. angeht. Bei Pylons musst du mehr selber entscheiden, wie du es einsetzen willst. Ich hab mich für Pylons+Mako+SQLAlchemy+AuthKit entschieden (und kein Elixir). -- Gerhard
ich bin in die Verlegenheit gekommen für eine Applikation ein web-frontend schreiben zu müssen.
Hallo Liste, ich wollte nur den thread abschliessen und kurz berichten. Nachdem ich ALLE eure Vorschläge gelesen und die entsprechenden Websites durchgelesen habe, habe ich mich frisch ans praktische werk gesetzt. 1) TurboGears. Habe da zwar was mit zustanden bekommen, aber so wirklich gefällt es mir nicht. 2) Pylons. Ist mir zu kompliziert. 3) django Ich glaube das ist es. Es gefällt mir vom händling und die ersten seiten stehen schon. Ich werde mich mit djange mal näher beschäftigen. Danke euch allen für die viele Tips. Sie waren mir alle sehr hilfreich. -- cu Roland M. Kruggel mailto:rk.liste@bbf7.de http:www.bbf7.de System: Intel, Debian etch, 2.6.21, xfce4, KDE 3.5 ------------ Zufallszitat Sein Gewissen ist rein - er hat es nie benutzt.
participants (14)
-
Andreas Jung -
Diez B. Roggisch -
Gerhard Haering -
Jens Diemer -
Jochen Schulz -
Kai Festersen -
lumbricus＠gmx.net -
Marek Kubica -
Markus Majer -
Roland M. Kruggel -
Stefan Behnel -
Stephan Diehl -
Sven Broeckling -
Sven Bröckling