Ein wenig Dynamik & ein erstes Hallo :)

Sockets, TCP/IP, (XML-)RPC und ähnliche Themen gehören in dieses Forum
Antworten
D-STaaR
User
Beiträge: 4
Registriert: Dienstag 23. September 2008, 13:33

Hallo,

das es hier mein erster Post ist stell ich mich mal kurz vor. Ich studiere Medieninformatik im 3. Semester und bin mit Python zum ersten mal im Fach Betriebssysteme in Berührung gekommen. Anstatt langweilige Shellskripte zu schreiben haben wir viele Dinge in Python geschrieben.

Soo mein Problem bist jetzt habe ich nur kleine Skripte für die Übungen geschrieben .. und nichts mit Internetprogrammierung und Python am Hut gehabt. Also ich möchte einen Teil einer Website so gestalten, dass nach dem klick auf einen Button sich der Inhalt eines bestimmten bereiches selber neu lädt.

Sprich ich klicke auf ein Button und es kommt zB der nächste Datensatz aus einer DB, welcher in einer Liste etc. gespeichert ist.

Vielleicht habt ihr ein wenig Hilfe für mich :)
Panke
User
Beiträge: 185
Registriert: Sonntag 18. März 2007, 19:26

Stichwort: Ajax.
Dauerbaustelle
User
Beiträge: 996
Registriert: Mittwoch 9. Januar 2008, 13:48

Hm... Stichwort Django oder Werkzeug und wie der vorposter schon sagt ajax.
Y0Gi
User
Beiträge: 1454
Registriert: Freitag 22. September 2006, 23:05
Wohnort: ja

Auf jeden Fall JavaScript. Eine große Hilfe ist jQuery.
D-STaaR
User
Beiträge: 4
Registriert: Dienstag 23. September 2008, 13:33

Ok .. sowas habe ich mir schon fast gedacht, leider habe ich nicht die Zeit mich in JScript einzuarbeiten und muss erstmal auf eine andere Lösung zurückgreifen. Gibt es denn auch kleinere Frameworks die nicht den riesen Umfang wie Django bieten, dafü aber trotzdem dynamisch arbeiten. Im Grunde ist mir die Arbeit mit DB wichtig.

Grüße
sma
User
Beiträge: 3018
Registriert: Montag 19. November 2007, 19:57
Wohnort: Kiel

Djangos Stärke ist IMHO die gute und umfangreiche Dokumentation. Vielleicht wirkt es auf dich daher so viel. Den Eindruck "riesen Umfang" kann ich nicht teilen, sondern finde Django angenehm klein und zugänglich.

Wenn du nur auf Datenbanken zugreifen willst, aber direktes SQL vermeiden willst, wäre eine Alternative http://www.sqlalchemy.org/ und das ist (gefühlt) umfangreicher als das komplette Django-Rahmenwerk. Ein etwas einfacherer ORM wäre http://www.sqlobject.org/. Schließlich gibt es noch https://storm.canonical.com/. Letzterer hat allerdings kaum Dokumentation.

Wenn du dich nicht mit JavaScript auseinandersetzen willst, werden dir dynamische Webseiten schwer fallen. Du könntest, auf Ruby on Rails wechseln, wo "Ajax-Zeugs" (basierend auf Prototype) ins Rahmenwerk eingebaut wurde. Doch statt Ruby würde ich dann lieber JavaScript lernen. Die Sprache ist einfacher. Mir fällt noch GWT ein, was allerdings Java-Kenntnisse voraussetzt. Eigentlich alles keine ernsthaften Vorschläge. James Tauber hatte vor einigen Jahren übrigens mal die Idee von GWT auf Python übertragen und Pyjamas begonnen. Gerade in Zeiten neuer hochperformanter JavaScript-Engines vielleicht wieder eine interessante Idee.

Ansonsten fällt mir aber kein Python-Webrahmenwerk ein, welches Ajax direkt unterstützt. Die meisten Python-Entwickler scheinen sich nicht festlegen zu wollen, wollen immer alles können und daher häufig leider nichts richtig.

Stefan
D-STaaR
User
Beiträge: 4
Registriert: Dienstag 23. September 2008, 13:33

OK vielen Dank .. das GWT kenne ich und Java Kenntnisse sind vorhanden. Ich denke, da bin ich gleich zu Anfang auf eine richtige Nische gestoßen. Dann werde ich mir erstmal nochmal in aller Ruhe Django zu gemüte führen. Vielen Dank für die Tips Sma.
Y0Gi
User
Beiträge: 1454
Registriert: Freitag 22. September 2006, 23:05
Wohnort: ja

D-STaaR hat geschrieben:[...] leider habe ich nicht die Zeit mich in JScript einzuarbeiten [...]
JavaScript, nicht JScript! Oh, und wo wir dabei sind: JavaScript != Java ;)

sma hat geschrieben:[...] http://www.sqlalchemy.org/ und das ist (gefühlt) umfangreicher als das komplette Django-Rahmenwerk.
Das dürfte daran liegen, das SQLAlchemy im Sachen kann, von der das popelige Django-ORM nicht mal zu träumen wagt. Manchmal erreichen Projekte nämlich Punkte, an denen ein bisschen CRUD mit MySQL nicht mehr ausreicht, sondern Dinge ins Spiel kommen, die z. B. die Kosten für ein RDBMS wie Oracle erklären.
Ich persönlich würde Django nur mit SA benutzen wollen, anstatt ein weit weniger mächtiges und ausgereiftes ORM zu erlernen und zu benutzen.

sma hat geschrieben:Doch statt Ruby würde ich dann lieber JavaScript lernen. Die Sprache ist einfacher.
Du warst auch mal in der Lage, deutlich besser zu differenzieren ;)

sma hat geschrieben:Ansonsten fällt mir aber kein Python-Webrahmenwerk ein, welches Ajax direkt unterstützt. Die meisten Python-Entwickler scheinen sich nicht festlegen zu wollen, wollen immer alles können und daher häufig leider nichts richtig.
Django hat keine AJAX-Integration aus nachvollziehbaren Gründen - weil man keine JS-Lib vorschreiben will. Rails tut genau das und in letzter Zeit scheinen viele Rails-Entwickler auf jQuery umgestiegen zu sein; fragt sich, inwieweit die ehemalige Integration noch funktioniert oder als unnützer Ballast mitgeschleppt werden muss. Pylons geht mit den Railshelpern in die Richtung von Rails (Surprise!), bietet also eine Integration.

Dein letzter Satz ist vollkommen fehl am Platze und passt auch nicht zu dir - du solltest es besser wissen. In Python gibt es Frameworks, die nicht zuviel vorschreiben, damit Entwickler ihre eigenen Stacks bauen können. Wenn mir keine der Komponenten eines Frameworks gefällt, dann ist es für mich nutzlos. Also nehme ich eine Lösung die mir erlaubt, solche durchaus wichtigen Entscheidungen selbst zu treffen. Django hat zumindest erreicht, dass es nicht von der Liste potentieller Kandidaten für ein Projekt fliegt, weil es ein AJAX-Toolkit integriert, aber ein anderes verwendet werden soll.
D-STaaR
User
Beiträge: 4
Registriert: Dienstag 23. September 2008, 13:33

Ich weiss durchaus, dass JavaScript != Java ist, wie gesgat ich studiere Info und hatte 2 Semester die Ehre mit Java. Die Formulierung mit JScript (war für mich nur weniger tipparbeit) war dann wohl nicht so klug gewählt, muss ich zugeben.
Wie gesagt wir hatten Python in Betriebssysteme und in Sachen Web-Rahmenwerke hab ich noch nichts weiter gemacht, es hat mich nur interessiert bzw. habe ich gerade eine kleine Web-Applikation, für die sich Python mehr als anbietet.
sma
User
Beiträge: 3018
Registriert: Montag 19. November 2007, 19:57
Wohnort: Kiel

Y0Gi hat geschrieben:
sma hat geschrieben:[...] http://www.sqlalchemy.org/ und das ist (gefühlt) umfangreicher als das komplette Django-Rahmenwerk.
Das dürfte daran liegen, das SQLAlchemy im Sachen kann, von der das popelige Django-ORM nicht mal zu träumen wagt.
Was alles keine Rolle spielt, wenn dem ersten Autoren bereits Django zu groß und umfangreich erschien. Darauf zielte ich ab. Ob sqlalchemy mehr kann, spielt dabei keine Rolle. Zunächst ist es noch mehr zu lernen.

Y0Gi hat geschrieben:
sma hat geschrieben:Doch statt Ruby würde ich dann lieber JavaScript lernen. Die Sprache ist einfacher.
Du warst auch mal in der Lage, deutlich besser zu differenzieren ;)
Was bitte ist an dieser Aussage falsch? Wenn er sich nicht mit JS beschäftigen will, aber Ajax machen will, wäre Rails dank eingebautem Ajax eine Alternative. Allerdings, so mein Tipp, halte ich es dann doch für einfacher, JS zu lernen, als Ruby, nur um Rails mit seinen Remote-Funktionen einsetzen zu können.

Vielleicht hast du es für einen Scherz gehalten, aber JS ist eine interessante, lernenswerte Sprache (wenn man über ein paar unschöne Details hinweg sieht), die funktionale und objektorientierte Programmierung erlaubt.

Y0Gi hat geschrieben:Django hat keine AJAX-Integration aus nachvollziehbaren Gründen - weil man keine JS-Lib vorschreiben will.
Sich festzulegen, erfordert Mut. Diesen - und da provoziere ich gerne noch weiter - vermisse ich häufig. Ich halte Flexibilität nicht automatisch für eine Stärke. Häufig ist es eine verkappte Schwäche. Und außerdem: Zu viel Auswahl schwächt die Community, weil sich dann nämlich alle Leute verteilen, statt hinter einem Rahmenwerk (wie bei Rails) zu stehen.

Ansonsten, weil man bei Rails nichts direkt mit Prototype und Scriptaculous zu tun haben muss, sollte es doch nicht schwer sein, intern es durch jQuery zu ersetzen. Letztlich wird das gewählte Rahmenwerk zu einem Implementationsdetail. Wenn die Leute aber an Rails vorbei direkt auf das JavaScript zugreifen wollen - und, dann muss ihnen auch die mögliche Konsequenz bewusst sein. Doch das ist immer noch besser, als gar keine Entscheidung zu treffen und in einem Möglichkeitsraum zu schweben.
Y0Gi hat geschrieben:Dein letzter Satz ist vollkommen fehl am Platze und passt auch nicht zu dir - du solltest es besser wissen. In Python gibt es Frameworks, die nicht zuviel vorschreiben, damit Entwickler ihre eigenen Stacks bauen können.
Ich spüre Verärgerung. War der Satz vielleicht doch wahr? ;) Aus welchem Grund man sich nicht festlegen will, ist mir schon klar. Ich finde den Grund nur nicht überzeugend. Statt jedem Entwickler sein persönliches Rahmenwerk, würde ich mir lieber weniger größere Rahmenwerke wünschen, die eine so starke Community aufbauen, dass etwas bei bei Rails passiert und interessante Köpfe angezogen werden, auch weil die Sprache und das Rahmenwerk auf einmal kommerziell interessant werden.
Y0Gi hat geschrieben:Also nehme ich eine Lösung die mir erlaubt, solche durchaus wichtigen Entscheidungen selbst zu treffen.
Wenn du das kannst, gehörst du zu einer ganz kleinen Gruppe von Entwicklern. Denn um die Qualität von Rahmenwerken beurteilen zu können, braucht es Erfahrung und einen Überblick, den man sich erarbeiten muss. Wenn das jeder machen muss, kostet das viel Zeit, die man lieber in Programme stecken sollte. In Javaposse #207 (ein empfehenswerter Podcast, nicht nur um bei Java auf dem aktuellen Stand zu bleiben) betrachtete dieses Problem aus Java-Sicht, denn auch dort gibt es ja Webrahmenwerke und Bibliotheken wie Sterne an einem klaren Sommernachtshimmel.

Stefan
Y0Gi
User
Beiträge: 1454
Registriert: Freitag 22. September 2006, 23:05
Wohnort: ja

sma hat geschrieben:
Y0Gi hat geschrieben:
sma hat geschrieben:Doch statt Ruby würde ich dann lieber JavaScript lernen. Die Sprache ist einfacher.
Du warst auch mal in der Lage, deutlich besser zu differenzieren ;)
Was bitte ist an dieser Aussage falsch?
Nichts, aber das wollte ich damit auch nicht sagen. Vielmehr ging es mir um die unterschiedlichen Einsatzgebiete. Wenn er mit Python schon gearbeitet hat und jetzt dynamik auf Websites bringen will, kommt er kaum an JavaScript vorbei. Mit Ruby kann er den serverseitigen Code in einer anderen Sprache schreiben, das Problem besteht dann ohne JavaScript aber weiterhin.

Die interessanten Eigenschaften von JavaScript sind mir durchaus bekannt, da wollte ich nichts schlecht reden.

Ich bin es seit vielen Jahren gewohnt mit einzelnen Komponenten zu arbeiten und sie selbst mit einander zu verbinden. Das erlaubt mir, neue Technologien einzusetzen, ohne alles über den Haufen werden oder auf irgendein Release oder überhaupt die Entscheidung und Unterstützung eines Frameworks warten zu müssen.

Eine Art Rails für Python hat sicher seine Berechtigung, um Interessierte nicht zu überfordern und auf eine Anlaufstelle zu fokussieren. Django scheint sich schon weit in Richtung dieser Position vorgearbeitet zu haben.

In meinen Augen fußt es allerdings auf einer schlechten Basis, da es nicht den (sicherlich nicht zu Unrecht umstrittenen) Weg von TurboGears und Pylons geht und best-of-breed-Komponenten wie SQLAlchemy, Genshi, Mako und Konsorten integriert, sondern als Eigenentwicklung mit eigenen, technisch arg unterlegenen Komponenten daher kommt, mit denen man zu schnell an Grenzen stößt.

Würde Django jedoch auf eben solche bewährten, erstklassigen Projekte aufsetzen und trotzdem eine engere Integration und Erweiterung als Pylons vornehmen, wäre es für mich das ideale Framework, dass man pauschal erstmal jedem empfehlen kann. So aber heißt es dann "jo, für MS SQL oder Informix oder hohe Performance-Ansprüche kannste alles wegwerfen oder musst dir von Hand entsprechende Komponenten reinfrickeln". Doof, wenn man schon viel Arbeit reingesteckt hat und dann in einer Sackgasse gelandet ist. Ich kann nur hoffen, dass Django sich da weiter öffnet.

Ich sage nicht, dass mein Weg der richtige ist. Aber ich fange lieber auf 'ner zukunftssicheren Grundlage an und nehme dann - je nach Projekt - die Integration, Caching, i18n und was man jeweils noch so braucht, selbst vor.
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

sma hat geschrieben:Zu viel Auswahl schwächt die Community, weil sich dann nämlich alle Leute verteilen, statt hinter einem Rahmenwerk (wie bei Rails) zu stehen.
Es ist nun aber nicht so dass Rails nicht auch sein gutes halbes dutzend Alternativ-Frameworks zu Rails hätte, das Prominenteste wäre wohl Merb, aber auch Camping, Wee, Cerise und wie sie alle heißen. Wenn wir uns die Nutzerzahlen ansehen, dann hat Django in der Python-Welt analog zu Rails in der Ruby-Welt einen sehr großen "Marktanteil", wohingegen es in Python nach Django lange lange nichts gibt, danach vielleicht TG/Pylons (die aber bald mehr oder weniger das gleiche sind) und danach wieder lange nichts und dann kommen so Nischenframeworks und Libraries.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Y0Gi
User
Beiträge: 1454
Registriert: Freitag 22. September 2006, 23:05
Wohnort: ja

Wobei man da schon deutlich auf den Framework-Teil hinweisen sollte, denn Werkzeug, Paste, WebOb und evtl. noch existierende, ähnliche Libraries werden auch direkt genutzt, ohne dass ein Framework einbezogen wird. Bliebe noch z.B. CherryPy, das sowohl selbst als Framework bezeichnet werden kann, aber sich auch als Basis von TG und eingen Konsorten (die es wie Subway vermutlich nicht mehr gibt) einen Namen gemacht hat.
lunar

Y0Gi hat geschrieben:[ quote="sma"]Pylons geht mit den Railshelpern in die Richtung von Rails (Surprise!), bietet also eine Integration.
Pylons ist da schon wieder weg gegangen. Aktuelle Webhelper-Versionen kennzeichnen die ganzen von Rails portierten Funktionen als deprecated, und bietet stattdessen eigene, imho bessere Werkzeuge. Im Zuge dessen ist dann auch die Prototype/Scriptaculous Integration über Bord geflogen, wohl weil die Pylons-Entwickler bemerkt haben, dass die Leute trotz der vorhandenen Integration lieber jQuery nutzen, weil es vielen offenbar besser gefällt.

Ansonsten ack.
farid
User
Beiträge: 95
Registriert: Mittwoch 8. Oktober 2008, 15:37

Y0Gi hat geschrieben:Bliebe noch z.B. CherryPy, das sowohl selbst als Framework bezeichnet werden kann, aber sich auch als Basis von TG und eingen Konsorten (die es wie Subway vermutlich nicht mehr gibt) einen Namen gemacht hat.
+1 für CherryPy. Wird viel häufiger eingesetzt (auch stand-alone) als man glaubt.

Die Frage ist natürlich immer, was man von einem Webframework erwartet und wieviel zusätzlichen Kram man benötigt.
Antworten