Ich bin ein Neuling, um zu zope und ich arbeitete vor etwa 2,5 Jahren auf Django. Als ich zum ersten Mal in Zope (v2) gesprungen bin (nur weil meine neue Firma es seit 7 Jahren benutzt), stellte ich mich diesen Fragen. Bitte hilf mir, sie zu verstehen.
Was ist der "wahre" Zweck von zodb als solcher? Ich weiß, was es tut, aber erzähle mir eine großartige Sache, die zodb macht und ein Framework wie Django (welches kein zodb hat) vermisst.
Update: Basierend auf den Antworten, ersetzt Zodb die Notwendigkeit für ORM. Sie können das Objekt direkt in der Datenbank speichern (zodb selbst).
Eines der wichtigsten Features von Zope ist die TTW-Philosophie (Durch das Web oder Entwickeln mit ZMI). Aber ich (und jeder Entwickler) bevorzuge die Entwicklung auf der Basis von Dateisystemen (unter Verwendung der Versionskontrolle, unter Verwendung von Eclipse, unter Verwendung eines beliebigen Lieblingswerkzeugs außerhalb von Zope). Wo wird dieses TTW tatsächlich verwendet?
Das ist der Große. Was "EXTRA Stuff" bringt Zope's Acquistion im Vergleich zu Python / Django Inheritance.
Ist es wirklich eine gute Idee, von Django nach Zope zu kommen?
Jede Seite wie djangosnippets.org für Zope (v2)?
Das Wichtigste zuerst: Aktuelle zope2-Versionen enthalten auch alle von zope3. Und wenn Sie sich moderne zope2-Anwendungen wie Plone ansehen, werden Sie sehen, dass es eine Menge "Zope 3" (jetzt "Zope Tool Kit", ZTK) unter der Haube verwendet.
Der eigentliche Zweck des ZODB: Es ist eine der wenigen Objektdatenbanken (im Gegensatz zu relationalen SQL-Datenbanken), die eine breite Anwendung finden. Sie können "nur" alle Ihre Python-Objekte dort speichern, ohne einen objektrelationalen Mapper verwenden zu müssen. Nein "wähle * von xyz" unter der Haube. Und das Hinzufügen eines neuen Attributs auf einem Zodb-Objekt "hält" diese Änderung gerade noch aufrecht. Luxuriös! Besonders praktisch, wenn Ihre Daten nicht einfach einer strengen relationalen Datenbank zugeordnet werden können. Wenn Sie können leicht zuordnen: Verwenden Sie einfach eine solche Datenbank, ich habe sqlalchemy ein paar Mal in Zope-Projekten verwendet.
TTW: Wir sind davon zurückgekommen. Zumindest hat die Zope2-Methode von TTW tatsächlich alle Nachteile, die Sie befürchten. Keine Versionskontrolle, keine externen Tools, etc. Plone experimentiert (google for "dexterity") mit netten expliziten ZOPE 3 Möglichkeiten der TTW-Entwicklung, die immer noch auf das Dateisystem abgebildet werden können.
TTW: Der zodb macht es einfach und billig, alle Arten von Konfigurationseinstellungen in der Datenbank zu speichern, so dass Sie in der Regel viele Dinge über den Browser anpassen können. Dies zählt jedoch nicht als typische TTW-Entwicklung.
Akquisition: handy Trick, obwohl es zu einer großen Namespace-Verschmutzung führt. Zweischneidiges Schwert. Um die Debuggability und Maintenance zu verbessern, versuchen wir in den meisten Fällen darauf zu verzichten. Die Übernahme findet innerhalb des "Objektgraphen" statt, also denke "Ordnerstruktur innerhalb der Zope-Site". Ein Aufruf von "contact_form" drei Ordner nach unten kann immer noch das "contact_form" auf dem Stamm der Website finden, wenn es nicht irgendwo dazwischen gefunden wird. Zweischneidiges Schwert!
(Und eine regelmäßige objekt-orientierte Python-Vererbung findet natürlich überall statt).
Umzug von Django nach Zope: eine wirklich gute Idee für bestimmte Probleme und unsinnig für andere Probleme :-) Zope2 / Plone-Firmen haben ziemlich viele Django-Projekte für bestimmte Projekte gemacht, typischerweise diejenigen, die 99% Prozent davon haben ihr Inhalt in einer relativ einfachen SQL-Datenbank. Wenn Sie mehr im Content-Management sind, ist Zope (und Plone) wahrscheinlich besser.
Zusätzlicher Tipp: Fokussieren Sie nicht nur auf zope2. Die "Komponentenarchitektur" von Zope3 bietet viele Funktionen für die Erstellung größerer Anwendungen (auch ohne Web). Schau dir zum Beispiel grok ( Ссылка ) für ein freundliches Zope an. Die reine Komponentenarchitektur ist auch in Django-Projekten verwendbar.
Auf dem ZODB:
Eine andere Art zu fragen: "Was ist der wahre Zweck des ZODB?" ist zu fragen: "Warum wurde der ZODB ursprünglich erschaffen?"
Die Antwort darauf ist, dass das Projekt sehr früh, etwa 1996, begonnen wurde. Dies war vor der Existenz von MySQL oder PostgreSQL, als die miniSQL-Datenbank (eine frei verwendbare, aber nicht freie Software) noch immer gebräuchlich war. oder große Geld-Datenbanken wie Oracle. Python stellte das Pickel-Modul zur Verfügung, um Python-Objekte auf dem Datenträger zu serialisieren - aber die Serialisierung ist eine niedrigere Ebene, sie erlaubt keine Funktionen wie Transaktionen, gleichzeitige Schreibvorgänge und Replikation. Das bietet der ZODB.
Es wird noch heute in Zope verwendet, weil es gut funktioniert. Wenn Sie in relationalen Datenbanken keine vorhandenen Skillsets haben, ist es einfacher zu lernen, das ZODB als eine relationale Datenbank zu verwenden. Es sind auch einfachere Anwendungsfälle möglich. Wenn Sie beispielsweise ein Befehlszeilenskript haben, das einige Konfigurationsinformationen speichern muss, bedeutet die Verwendung einer relationalen Datenbank, dass Sie einen Datenbankserver ausführen müssen, um ein wenig Konfiguration zu speichern. Sie könnten eine Konfigurationsdatei verwenden, aber das ZODB funktioniert auch ganz gut, weil es eine einbettbare Datenbank ist. Das bedeutet, dass die Datenbank im selben Prozess wie der Rest Ihres Python-Codes ausgeführt wird.
Beachten Sie auch, dass die API zum Speichern von Objekten in Containern zwischen Zope 2 und Zope 3 unterschiedlich ist. In Zope 2 werden Container als Attribute gespeichert:
%Vor%In Zope 3 verwenden sie dieselbe Schnittstelle wie der Python-Standardwörterbuchtyp:
%Vor%Dies ist ein weiterer Grund, warum es einfacher ist, das ZODB als das Django-ORM zu lernen, da Django über eine eigene Schnittstelle für sein ORM verfügt, die sich von Pythons bestehenden Schnittstellen unterscheidet.
Durch das Internet (TTW):
Noch einmal, der Grund für TTW ist zurück, als Zope entwickelt wurde. Während es albern scheint, mit bekannten Entwicklertools wie Subversion oder Mercurial zu brechen, wurde Zope in den späten 90ern entwickelt, als das einzige kostenlose Versionskontrollsystem CVS war. Zope 2 hatte seine eigenen einfachen Versionskontrollfähigkeiten, und sie waren so gut wie CVS (was bedeutet, "sie waren begrenzt und sucky."). UNIX-Workstations kosten damals viel mehr Geld und hatten viel weniger Ressourcen. Daher waren die Systemadministratoren viel geschützter und vorsichtiger bei der Serververwaltung. TTW erlaubte Leuten, die normalerweise nicht in der Lage wären, Code auf den Server mit sysadmin intervation hochzuladen, eine Möglichkeit, dies zu tun.
Mit Text-Editoren haben Emacs und vi FTP-Modi und Zope 2 kann auf einem FTP-Port hören. Dies würde es Ihnen erlauben, Code zu entwickeln, der im ZODB (editierbares TTW) gespeichert wurde, aber es war üblich, diesen Code mit einem Emacs oder vi zu bearbeiten.
Heute in Zope wird TTW seltener benutzt oder gefördert, da es keinen Sinn mehr macht, dies zu tun. Speicherplatz ist billig, Server sind (relativ) billig und es gibt viele Entwickler-Tools, die mit dem Standard-Dateisystem interagieren wollen.
Akquisition:
Es war ein Fehler. Es war eine sehr verwirrende Funktion, die viele unerwartete Dinge verursacht hat. Theoretisch gibt es einige interessante Ideen, aber in der Praxis ist es am besten, sie in den Müll zu werfen und wenig praktischen Nutzen zu haben.
Umzug von Django nach Zope:
Die Arbeiten an Zope 3 im Jahr 2001 begannen. Damit wurden viele Probleme mit Zope 2 behoben. Es ist ein Beweis für die Zope-Gemeinschaft, dass Zope 2 immer noch aktiv und gut gepflegt ist, aber es ist kaum State-of-the-Art. Zope 2 ist wirklich nur interessant, um aus einer historischen Perspektive zu lernen.
Zope 3 entwickelte sich schließlich in ein paar verschiedenen Richtungen, und so werden moderne Inkarnationen von Zope am besten in Form von Grok, BFG oder Bobo ausgedrückt.
Grok ist Zope 3 am nächsten und als solches ist es ein ziemlich großer Rahmen - es kann manchmal ziemlich überwältigend sein, wenn er sich durch seine Code-Basis hindurcharbeitet. Genau wie Django oder jedes andere Full-Stack-Framework müssen Sie nicht jeden Teil von Grok verwenden, aber es kann ziemlich einfach sein, das Grundlegende zu erlernen und Web-Anwendungen damit zu erstellen. Die Convention-over-Configuration ist unübertroffen, und ihre klassenbasierten Views geben ihr eine wesentlich engere, wohl sauberere Code-Basis als eine Django-Webanwendung. Sein URL-Routing-System ist extrem flexibel, aber auch überentwickelt.
BFG ist ein "Bezahlen für nur, was Sie essen" -Framework geschrieben von langjähriger Zope-Entwickler Chris McDonough. Als solches liegt es näher an Pylons im Geiste, wo nur die Teile enthalten sind, die für einen Rahmen als wesentlich oder wesentlich erachtet werden. Es spielt auch sehr gut mit WSGI. Es verwendet nur ein paar zentrale Zope-Pakete.
Bobo ist ein "Mikro-Framework". Es ist nur eine Möglichkeit, URLs zu routen und eine App bereitzustellen. Es verwendet keine Zope-Pakete, also ist es nicht streng in der Zope-Familie von Web-Frameworks. Aber es wurde von Zopes Schöpfer Jim Fulton geschrieben, der ursprünglich den Verlagsteil von Zope "Bobo" nannte.Der ursprüngliche Bobo, der in den frühen 90ern geschrieben wurde, ordnete URLs zu Paketen und Modulen zu, also wenn Ihr Quellcode wie folgt ausgelegt war:
%Vor%Sie könnten eine URL haben wie:
%Vor%Das war sehr unflexibel und wurde durch URL Traversel in Zope 2 ersetzt, was ziemlich komplex ist. Bobo benutzt Routes, also ist es ein Mittelweg zwischen tot-einfacher URL-Auflösung und komplexer URL-Auflösung - ungefähr so komplex wie Djangos URL-Auflösungsmaschinen.
Ich antworte ohne viel Erfahrung auf beiden, aber ich hatte die Möglichkeit, beides zu manipulieren, damit ich Ihnen meine Meinung zu einigen Ihrer Fragen mitteilen kann.
1) Was ist der "wahre" Zweck von zodb? so wie? Bedeutung Ich weiß, was es tut, aber sag mir eine großartige Sache, die zodb tut und ein Framework wie Django (die hat keine zodb) vermisst
Laden Sie die Verteilung über ZEO und suchen Sie über ZCatalog. Django ist unter diesem Gesichtspunkt sehr niedrig. Um das gleiche zu erreichen, müssten Sie viele dreieckige Räder re-implementieren. Etwas, das ich ziemlich bald gelernt habe, ist: Mach dich nicht mit Datenbankproblemen auf niedriger Ebene herum. Du wirst sie vermasseln. Es ist eine Dose Würmer, Dune Größe .
Warum also Django ORM wählen? Sie sollten auch überlegen, ob YAGNI . Django ist einfach und eigenständig, Dokumentation ist Premium, und wenn (wenn) Ihre Site so stark wächst, werden Sie den Wechsel zu einem besseren ORM (oder zu einem reinen OODB, im Falle von ZODB) tun ) später.
2) Es wird gesagt, einer der Killer der Zope Feature ist das TTW (über das Internet oder Entwickeln mit ZMI) Philosophie. Aber Ich (und jeder Entwickler) bevorzugt Dateisystembasierte Entwicklung (unter Verwendung von Versionskontrolle mit Eclipse unter Verwendung von jedes Lieblingswerkzeug außerhalb von Zope). Dann Wo wird dieses TTW tatsächlich verwendet?
Ich kann diese Frage nicht richtig beantworten, aber ich würde nicht sagen, dass es grundsätzlich schlecht ist, sich mit einem solchen Ansatz zu entwickeln. Natürlich ist es eine Änderung der Denkweise, und ich bevorzuge auch die Entwicklung auf Dateisystembasis.
4) Ist das wirklich ein guter Schritt zur Arbeit? Zope, aus Django?
Zope 3 ist sehr modular, so dass Sie viele seiner Komponenten von django verwenden können. Ich würde jedoch davon abraten. Sie können natürlich, aber was ich am problematischsten fand, ist der Mangel an Hilfe. Es gibt nicht viele Leute, die zope Komponenten und Django gleichzeitig benutzen. Früher oder später wirst du ein Problem haben und Google wird nicht helfen. An diesem Punkt wirst du erkennen, dass du, wenn dein Leben ein Videospiel war, es definitiv auf Schwierigkeitsstufe spielen wirst (vielleicht extrem, wenn du deine Nase in den Zope-Code stecken musst).
Eine sehr gute Referenz auf ZODB ist ZODB / ZEO Programmiererhandbuch . ZODB ist kein ORM. Es ist eine echte Objektdatenbank. Python-Objekte bleiben transparent in der Datenbank gespeichert, ohne dass sie sich darum sorgen müssen, wie sie in eine für die Datenbank geeignete Darstellung umgewandelt werden können. Jedes pickbare Python-Objekt kann im ZODB gespeichert werden. Relationale Datenbanken eignen sich für große Mengen von flachen Daten (wie Mitarbeiterdatensätze), während ZODB am besten für hierarchische Daten geeignet ist (typischerweise in Webanwendungen). Ich persönlich benutze Zope 3 für meine Anwendungen. Ich habe nie TTW Arbeit gemacht. Der beste Teil der Verwendung von ZODB war die Tatsache, dass ich mich nie darum kümmern musste, wie ich Daten speichern werde und wie sich die Dinge ändern würden, wenn ich meine Software von einer Version auf die nächste aktualisiere. Wenn ich beispielsweise einer Python-Klasse ein neues Attribut hinzufüge, muss ich lediglich einen Standardwert als Klassenattribut angeben. Es wird dann automatisch für alle Objekte verfügbar, die mit der vorherigen Version derselben Klasse erstellt wurden. Das Entfernen eines Attributs ist eine einfache del-Operation für vorhandene Objekte. BTW, ZODB kann unabhängig in jeder Art von Python-Anwendung verwendet werden und ist nicht nur mit ZOPE-Plattform gekoppelt. Ich liebe die Tatsache, dass ich mich bei der Arbeit an Python-Anwendungen nicht um die wichtigen Dinge von SQL kümmern muss, anstatt an ZODB. Und natürlich, wenn Sie einen Datenbankserver benötigen, um mehrere Kopien Ihrer Anwendung auf demselben Server laufen zu lassen, kommt Ihnen ZEO zusätzlich zu ZODB zu Hilfe.
Zope begann mit der Idee, eine Objektveröffentlichungsumgebung zu sein. Aus dieser Perspektive war die Zuordnung der URL direkt zur Objekthierarchie in ZODB großartig. Die URLs spiegeln einfach die Hierarchie der Objekte wider. Jetzt, wo die URL betrachtet wird, gibt es immer die Debugging-Schnittstelle von Rotterdam als Hilfe. Für die Entwicklungsarbeit halte ich die Entwicklungsflags in der Zope-Konfiguration an und schaue den Inhalt von ZODB über die Rotterdam-Schnittstelle an. Rotterdam Skin bietet eine großartige Möglichkeit, die Python-Objekte, die im ZODB gespeichert sind, zu betrachten und herauszufinden, dass die URLs viel interaktiver sind. Darüber hinaus registriere ich sie für große Container in meinem ZODB als permanente Dienstprogramme innerhalb des Site-Managers (Zope 3-Sites und Site-Manager). Überall in meinem Code, wenn ich Zugriff auf solche Container benötige, ist alles was ich tueUtility (IMyContainerType). Ich muss mich nicht einmal an die genauen Positionen dieser Container innerhalb der Codebasis erinnern. Sie sind einmal beim Site Manager registriert und werden über getUtility () -Aufrufe überall innerhalb der Codebasis verfügbar. Und die URLs unterstützen auch Namespaces. Zum Beispiel können Sie mit dem Namespace ++ skin ++ die Skin Ihrer Webanwendung jederzeit ändern. Mit dem Namespace ++ Sprache ++ können Sie jederzeit die bevorzugte Sprache Ihrer Benutzeroberfläche ändern. Mit dem ++ Attributen ++ Namespace können Sie auf einzelne Attribute eines Objekts zugreifen. URLs sind einfach viel mächtiger und viel anpassbarer. Und Sie können Traversaladapter schreiben, eigene Namespaces definieren, um die Fähigkeiten Ihrer URLs zu verbessern. Um ein Beispiel zu geben, sind alle Seiten, auf die direkt über die Webschnittstelle zugegriffen werden kann, Teil meiner Standard-Skin. Während alle Seiten, die durch Hintergrund-AJAX-Aufrufe aufgerufen werden, sich unter einer anderen Skin befinden. Auf diese Weise kann man verschiedene Arten von Authentifizierungsmechanismen in verschiedenen Skins implementieren. Im Haupt-Skin wird einer bei einem Authentifizierungsfehler auf eine andere Anmeldeseite umgeleitet. Für AJAX-Seiten könnte man einfach einen HTTP-Fehler erhalten. Dies könnte zentral erledigt werden. Zope 3 Objekte haben Schnittstellen und eine Ansicht kann für mehrere Schnittstellen definiert werden. Wo auch immer Sie ein Objekt haben, das die angegebene Schnittstelle unterstützt, werden alle zugehörigen Ansichten automatisch verfügbar und alle diese URLs sind automatisch gültig. Wenn Sie darüber nachdenken, ist es viel mächtiger als eine einzelne Python-Datei oder XML-Datei, in der die URLs fest codiert sind. Ich weiß nicht wirklich viel über DJango und J2EE, also kann ich nicht sagen, ob sie gleichwertige Fähigkeiten haben.
ZODB ist eine OO-artige Datenbank, die keine Schemadefinition benötigt. Sie können (fast) alle Arten von Objekten erstellen und diese beibehalten.
Das TTW ist manchmal nervig, aber Sie können den ZOPE-Objektbaum mit webdav mounten. Dann können Sie die Vorlagen und Skripte mit Ihrem bevorzugten Editor bearbeiten.
ZOPE ist besonders leistungsfähig, um CMS-ähnliche Systeme zu erstellen, IMHO da es noch unerreicht ist - du müsstest viel durchmachen, damit es in Django gleich gut funktioniert.
Und durch das TTW haben eigentlich Nicht-Entwickler wie Designer eine gute Chance, z.B. Vorlagen und CSS, ohne dass Entwickler interagieren müssen.
+1 zu Wheats Antwort, oben: "Zope 2 ist wirklich nur interessant, um aus einer historischen Perspektive zu lernen". Ich habe für ein paar Jahre Zope Dev für eine große Site gemacht, 50% Zope 2, 50% Zope 3. Schon damals (das war vor 2 Jahren) arbeiteten wir daran, alles von Zope 2 zu migrieren. Es sei denn, Sie haben schon eine Menge in ein bestehendes Zope 2-Projekt investiert, gibt es keinen Grund, es zu nutzen; da ist einfach nicht viel Zukunft. Und wenn Sie ein großes existierendes Zope 2-Projekt haben, würde ich vorschlagen, sich ein Produkt anzusehen, das Five heißt (ein Witz: 2 + 3 = 5), der auf
zieltermöglicht Ihnen die Integration von Zope 3 Technologien in Zope 2. Unter Anderen ermöglicht es Ihnen, Zope 3 zu verwenden Schnittstellen, ZCML-basierte Konfiguration, Adapter, Browserseiten (einschließlich Skins, Ebenen und Ressourcen), automatisierte Hinzufügen und Bearbeiten von Formularen basierend auf Schemas, Objektereignisse sowie Zope 3-Stil i18n Nachrichtenkataloge.
Wenn alles gesagt und getan ist, ist Zope 3 ein sehr anderer Rahmen als 2, und IMHO, ein viel besserer (wenn auch komplizierter). TTW ist optional und wird in den meisten Fällen nicht empfohlen. Implizite Erfassung ist weg.
Sieht so aus, als hätten die Leute hier geklärt, warum Sie vielleicht den ZODB benutzen sollten, also dachte ich, ich würde noch etwas über Zope 3 (oder Zope 2 mit Five) erwähnen, das ist gut. Zope verfügt über ein sehr leistungsfähiges System zur Verdrahtung verschiedener Anwendungskomponenten, die Zope Component Architecture genannt werden (ZCA). Sie können Komponenten schreiben, die mehr oder weniger autonom und wiederverwendbar sind und die standardisiert zusammengesteckt werden können. Ich mache jetzt meistens Django-Entwicklung und manchmal vermisse ich die ZCA. In Django ist die Fähigkeit, wiederverwendbare Komponenten zu schreiben, begrenzt und irgendwie ad hoc. Aber, wie Reinout sagt, dass zope.component (wie die meisten Zope-Pakete, einschließlich des ZODB) außerhalb des Zope-Frameworks arbeitet und in einem Django-Projekt verwendet werden könnte.
Das heißt, der ZCA hat seine Nachteile, einer davon ist der mühsame Prozess der Registrierung Ihrer Komponenten in XML-Dateien; es fühlte sich immer ein bisschen Java-esqe an. Ein Grund, warum ich Grok http://grok.zope.org/ wirklich mag, ist, dass es oben auf zope.component sitzt und viel tut von diesem Grunzen arbeite für dich.
Unterm Strich also: Zope 2 ist meistens eine Sackgasse. Wenn Ihr Arbeitgeber dazu in der Lage ist, schauen Sie sich Zope 3 oder mindestens fünf an. Ich denke du wirst feststellen, dass Zope 3 im Vergleich zu Django eine steile Lernkurve hat, also ist es vielleicht eine gute Idee, über Grok zu kommen, was viele der raueren Kanten von Zope 3 glättet. Aber ich denke für eine wirklich große oder komplexe Webanwendung mit vielen beweglichen Teilen würde ich für Zope über Django gehen (und ich sage das als jemand, der Django wirklich sehr mag). Für kleinere Projekte wäre Django wahrscheinlich schneller. Die Quantifizierung von "groß" und "klein" in diesem Kontext ist jedoch schwierig und würde wahrscheinlich ein paar tausend weitere Wörter erfordern. Wenn Sie sich wirklich für Zope 3 interessieren, ist das Buch von Philipp von Weitershausen definitiv der richtige Ort.
Tags und Links python django zope zodb acquisition
