Hi ihr lieben leute,
ich hab neulich das framework glashammer gefunden ( glashammer.org ) welches wohl auf werkzeug und anderen coolen geschichten aufsetzt... hat schon jemand von euch was damit gemacht? was haltet ihr davon?
gruesse
Glashammer
Das Framework und die zwei aktivsten Entwickler sind mir bekannt. Dass es eins auf Werkzeug-Basis gibt, betrachte ich auch als wichtig. Ich benutze allerdings fast immer Genshi und nicht Jinja, von daher kommt es für mich so nicht in Frage (eventuelle Austauschbarkeit hin oder her, aber ein Framework lebt normalerweise davon, dass es an bestimmte Komponenten angepasst ist).
Auch ist die Menge des Codes, den ich für ein Web-App-Setup mit Werkzeug und Co. benötige und den sich meine Projekte teilen so gering, dass sich ein Auslagern in eine eigene Abhängigkeit kaum rechtfertigen lässt. In der Vergangenheit habe ich das mit `Upraise`, damals auf Basis von Paste + Co., mal durchgeführt. Doch durch die Entstehung von und den Wechsel auf Werkzeug ist davon ein guter Teil weggefallen und meine bevorzugte Applikationsstruktur hat sich soweit geändert, dass ich fast den kompletten Code (der auch Konzepte von PasteDeploy und PasteScript benutzt) über den Haufen werfen kann. Ergo bleibe ich lieber bei vielleicht zwei Modulen, die ich in eine neue Anwendung kopiere und anpasse, anstatt mich um abgeschlossene Releases zu kümmern und früher oder später in allen meinen Applikationen Neuerungen hinterher zu patchen.
Wer Jinja mag und/oder schon benutzt, mag hier aber durchaus mit Glashammer gut beraten sein.
Auch ist die Menge des Codes, den ich für ein Web-App-Setup mit Werkzeug und Co. benötige und den sich meine Projekte teilen so gering, dass sich ein Auslagern in eine eigene Abhängigkeit kaum rechtfertigen lässt. In der Vergangenheit habe ich das mit `Upraise`, damals auf Basis von Paste + Co., mal durchgeführt. Doch durch die Entstehung von und den Wechsel auf Werkzeug ist davon ein guter Teil weggefallen und meine bevorzugte Applikationsstruktur hat sich soweit geändert, dass ich fast den kompletten Code (der auch Konzepte von PasteDeploy und PasteScript benutzt) über den Haufen werfen kann. Ergo bleibe ich lieber bei vielleicht zwei Modulen, die ich in eine neue Anwendung kopiere und anpasse, anstatt mich um abgeschlossene Releases zu kümmern und früher oder später in allen meinen Applikationen Neuerungen hinterher zu patchen.
Wer Jinja mag und/oder schon benutzt, mag hier aber durchaus mit Glashammer gut beraten sein.
Hm, die Farbgebung der Webseite ist für mich sehr gewöhnungsbedürftig. Der Anfang der Dokumentation schafft es nicht, mich von den Vorteilen dieses Rahmenwerks zu überzeugen.
Es heißt dort, man will bewährte Komponenten zusammenstecken, doch darin liegt IMHO noch kein Wert an sich. Djangos Komponenten sind auch seit 3 Jahren bewährt. Man will gleichzeitig Entscheidungen treffen, was zusammengesteckt wird. Pylons macht das aber IMHO implizit ebenfalls, indem gewisse Dinge in ihrem Tutorial vorgestellt werden. Werkzeug und Jinja zusammenzustecken wird ja schon in Werkzeugs Tutorial nahegelegt und beides kommt "aus einer Hand". WTForms kenne ich nicht, sieht aber im Prinzip so aus, wie was Django bietet. Für einen ORM entscheidet sich Glasshammer nicht und widerspricht sich so im eignen Anspruch, Entscheidungen zu treffen.
Der Wert eines Rahmenwerks liegt IMHO darin, dass man Zeit spart und/oder bewährte Entwurfsmuster nahegelegt bekommt. So finde ich Djangos vorgehen, den Pfad zu den Templates über die settings.py zu definieren besser, weil leichter pro Projekt austauschbar, als wenn man dies in `setup()` mitten im Programm macht. Ich sehe nicht, was prinzipiell anders (oder besser) ist, als wie Django - das ich recht gut kenne - funktioniert.
Ein Vorteil mag der wählbare ORM sein. Der sich daraus ergebende Nachteil ist aber, dass man keine wiederverwendbaren Anwendungsmodule erstellen kann, weil es keinen Standard gibt, den alle Entwickler teilen. Und dieser überwiegt IMHO.
Aber ansonsten? Ist es einfacher? Schneller? Leichtgewichtiger? Ich habe zumindest (noch) kein Admin UI, über das Forms-Dingens habe ich in der Doku nichts gesehen - ist File-Upload möglich? Was ist mit Testen? Logging? Welche Unterstützung gibt es sonst bei der Entwicklung?
Mal sehen, wie sich Glasshammer enwickelt...
Stefan
Es heißt dort, man will bewährte Komponenten zusammenstecken, doch darin liegt IMHO noch kein Wert an sich. Djangos Komponenten sind auch seit 3 Jahren bewährt. Man will gleichzeitig Entscheidungen treffen, was zusammengesteckt wird. Pylons macht das aber IMHO implizit ebenfalls, indem gewisse Dinge in ihrem Tutorial vorgestellt werden. Werkzeug und Jinja zusammenzustecken wird ja schon in Werkzeugs Tutorial nahegelegt und beides kommt "aus einer Hand". WTForms kenne ich nicht, sieht aber im Prinzip so aus, wie was Django bietet. Für einen ORM entscheidet sich Glasshammer nicht und widerspricht sich so im eignen Anspruch, Entscheidungen zu treffen.
Der Wert eines Rahmenwerks liegt IMHO darin, dass man Zeit spart und/oder bewährte Entwurfsmuster nahegelegt bekommt. So finde ich Djangos vorgehen, den Pfad zu den Templates über die settings.py zu definieren besser, weil leichter pro Projekt austauschbar, als wenn man dies in `setup()` mitten im Programm macht. Ich sehe nicht, was prinzipiell anders (oder besser) ist, als wie Django - das ich recht gut kenne - funktioniert.
Ein Vorteil mag der wählbare ORM sein. Der sich daraus ergebende Nachteil ist aber, dass man keine wiederverwendbaren Anwendungsmodule erstellen kann, weil es keinen Standard gibt, den alle Entwickler teilen. Und dieser überwiegt IMHO.
Aber ansonsten? Ist es einfacher? Schneller? Leichtgewichtiger? Ich habe zumindest (noch) kein Admin UI, über das Forms-Dingens habe ich in der Doku nichts gesehen - ist File-Upload möglich? Was ist mit Testen? Logging? Welche Unterstützung gibt es sonst bei der Entwicklung?
Mal sehen, wie sich Glasshammer enwickelt...
Stefan
*hust* Ich möchte ja ungern wieder mal draufhauen, aber Djangos ORM und Template Engine sind am unteren Ende der Skala dessen, was mir bisher in der WebApp-Welt begegnet ist.sma hat geschrieben:Djangos Komponenten sind auch seit 3 Jahren bewährt.
WTForms ist meines Wissens nach wie vor nur in einer Entwicklungsversion verfügbar; trotzdem könnte gerade die Integration in ein und die Pflege im Rahmen eines Frameworks ein Vorteil sein.
Bzgl. der Nicht-Wahl eines ORMs stimme ich sma ebenfalls zu. SQLAlchemy dürfte weitgehend als Quasi-Standard gelten und währe hier die naheliegende Wahl. Insbesondere die Integration wäre ein Pluspunkt, da sie nicht für jeden trivial ist.
Als einzigen Punkt, der gegen die Integration spricht, könnte ich mir vorstellen, dass man auch Applikationen ohne DB-Zugriff explizit ansprechen möchte. Wobei sich da die Frage stellt, inwieweit ein bisschen ungenutzer Glue-Code da noch ins Gewicht fällt.
Insgesamt scheint mir Glashammer wie so vieles die konsequente Paketierung und Veröffentlichung von Glue- und Utility-Code zu sein, den viele früher oder später schreiben, wenn sie nicht schon auf ein "fertiges" Framework setzen. Für so manchen Ein- oder Umsteiger dürfte das, insbesondere durch Tutorial und Dokumentation an sich, sehr hilfreich sein und auch die "Message" weiterer guter Komponenten in die Welt hinaus tragen.
Um jedoch langfristig als Framework zu bestehen, bedarf es da meiner Meinung nach noch weit mehr (vgl. Django bzgl. i18n, Caching und hastenichgesehn) - auch wenn es sich damit für meine persönlichen Kriterien umso weiter als Kandidat entziehen würde. Für Entwickler, die selbst wählen wollen, ist es vielleicht nicht mehr als ein gutes Beispiel - und denen wird es ein Framework in der Regel sowieso niemals recht machen können. Insgesamt fallen mir jedenfalls eine Menge kleinerer Frameworks ein, die möglicherweise sogar noch irgendwo zu haben sind, aber schon einen ähnlichen Weg gegangen sind, wie es Glashammer tun dürfte: Eine Art Manifestation dessen, was machbar ist, am Wegesrand.
Den von sma genannten Punkt, dass man eine Art Standard mit einem Framework setzt, auf dem aufbauend dann Erweiterungen mit der selben Schnittstelle geschaffen werden, halte ich für sehr wichtig. Man kann nicht für jede kleinere oder mittelgroße Anwendung, die man veröffentlichen möchte, ein komplettes Auth/Auth-System mitliefern und ggf. neu erfinden. Leider muss ich wieder mal betonen, dass die Politik hinter Django dafür sorgt, dass ich daran nicht teilhaben möchte. Zope hat schon so vieles sehr gut vor gemacht (und zwar Ewigkeiten vor den anderen), doch es ist für auch nur halbwegs leichtgewichtige Anwendungen meines Wissens einfach zu umfangreich und mächtig.