Symfony Day 09, seto-social und Symfony
...jap, auf eben jenem werde ich am Freitag mal aufschlagen. Beim Symfony-Framework handelt es sich um ein MVC-Webapp-Framework für PHP, mit dem ich die meiste meiner Arbeitszeit bei seto (die halten es dort jetzt schon fast ein Jahr mit mir aus \o/) zubringen muss/soll/darf und mit dem wir natürlich auch unser letztes, größeres Projekt "seto-social" erstellt haben.
Da dieses Projekt jetzt einigermaßen fertig ist, werde ich wohl erstmal damit anfangen worum es sich handelt...
seto-social
Nicht nur ist es einer der Gründe warum ich in letzter Zeit ziemlich beschäftigt war, sondern (das wird wohl auch eher jemanden interessieren) um eine Kombination aus Verwaltungsportal und sozialem Netzwerk. seto-social (so der Name auf den es getauft wurde) bietet dabei Verwaltungsfunktionen wie z.B. Mitgliederexport, Ical-Integration, umfangreiche Möglichkeiten zur Umfragenerstellung als auch
Foren, Aktionsstream mit Statusnachrichten und Informationen über alles was gerade im Netzwerk los ist, Wikis, Blogs, Newsletter, Bildergalerien und was weiß ich nicht noch alles...
Auf der rein technischen Seite sind wohl der Ajax-Editor für Wikiseiten und Umfragen, die Aktionen als Statusnachrichten mit nahezu endlosen Möglichkeiten und die Rechtevergabe auf Gruppenbasis (wobei Gruppen in einer Baumstruktur organisiert sind und Rechte vererbt werden, bzw. Termine sowohl nur Zweigen als auch dem halben/ganzen Baum zugeordnet werden können) das ineressanteste. (wasn Schachtelsatz -.-)
Das alles zu bauen war an sich schon nicht ganz einfach, es dann auch noch auf Geschwindigkeiten funktionieren zu lassen mit denen auch jemand arbeiten will war dann aber wohl der wirklich schwierige Teil. (rekursive Aufrufe sind toll! \o/)
Das Projekt hat jedenfalls richtig viel Spaß gemacht, ich konnte zum Glück die JS- und HTML-Sachen an Leute abgeben die mehr Spaß an sowas haben und hab mich etwas mehr auf die Interna des Systems konzentriert.
Ich glaube ich habe wirklich einiges neues über PHP und Symfony gelernt und das Projekt schein bereits recht erfolgreich zu sein. Wer demnächst eine Verwaltungsplatform braucht, bei der die betroffenen Personen so viel Spaß haben sollten dass sie selbst daran mitarbeiten, dem kann ich seto-social nur ans Herz legen.
Symfony
Das verwendete Framework, Symfony an sich ist weder besonders toll noch extrem evil, es erspart einem an vielen Stellen enorme Mengen Arbeit, hat dann aber wieder etliche Stellen an denen man flucht weil wieder irgendein Subsystem aussieht als wäre es von einer endlosen Menge Affen gehackt worden und die erste Version die ohne kritische Fehler durchlief wurde verwendet.
Wer schon jemals versucht hat ein ORDER BY RANDOM (ist möglich) in Propel (das ORM das via Default bei Symfony mitgeliefert wird) zu realisieren, einen Inplace-Editor etwas stärker anzupassen (über die bei Symfony dokumentierten Parameter hinaus, auch zu den vielen anderen die script.aculo.us wirklich anbietet) oder wer schonmal versucht hat ein paar Forms sehr dynamisch anpassbar zu verwenden, der wird wissen was ich meine.
Ursprüngliches Argument Symfony zu verwenden war wohl mal die stetig wachsende Community und die gute Dokumentation. Nun, die Dokumentation ist durchaus brauchbar, wenn auch einige Stellen immer wieder etwas der Entwicklung hinterher hinken und die Community.. naja, das werden wir ja dann am Freitag sehen.
Was auf jeden Fall bleibt ist die schlichte Tatsache dass seto schon seit geraumer Zeit seine Projekte ziemlich einheitlich mit Symfony realisiert und man ja auch nicht direkt eine wirklich gute Alternative hat. PHP ist für viele Projekte leider noch immer die Sprache der Wahl, ORM bringt wie jede andere Abstraktionsebene nunmal auch immer einen Verlust an Geschwindigkeit und Möglichkeiten mit sich und andere Frameworks sind jetzt auch nicht sonderlich viel besser.
Zumindest ist PHP mit diesem Aufsatz und ziemlich viel Selbstbeherrschung was Codequalität und spezifizierte Standards betrifft einigermaßen verwendbar. Das ist kein sonderlich berauschendes Urteil, aber noch immer besser als was ich über einige andere Sprachen da draußen sagen kann.
Vlt. wird man ja in Zukunft mehr mit Django oder Ruby on Rails machen... noch sehe ich das aber nicht ganz. Allein das Argument dass man inzwischen wohl fast jeden dämlichen Trick schonmal verwendet und für fast alle Probleme die das Framework hat einen Ausweg gefunden hat, wiegt nunmal schwer. Eine Umstellung auf die spezifischen Probleme eines anderen Frameworks wäre aufwändig...
Importierte/Alte Kommentare:
#1328: 31.Aug.2009 10:08 von SirSnookie
Naja zur Zeit hört man viel über CakePHP ... aber ich bin da irgendwie komplett raus. Ich hab zu viel mit Django experimentiert und bin damit eigentlich höchst zufrieden. Ich würde gern größere Projekte damit mal realisieren. Denn von der Programmiergeschwindigkeit ist man selbst erstaunt. Was ich leider nicht so gut finde an den ganzen PHP Frameworks -> Ramverbrauch ohne ende. Ich war damals von Magento total begeistert vor allem da er auf dem ZEND Framework basierte (wo ich mich gerade drinne eingearbeitet hatte). Aber nach der Installation wurde einem ganz anders, es ist ne eierlegende Wollmilchsau aber mit nem Bärenhunger an RAM und CPU Zeit. Ich bin gespannt in welche Richtung das in Zukunft schlagen wird.....
#1329: 01.Sep.2009 12:09 von Dr. Azrael Tod
Ich hab mich vor anderthalb Jahren mal kurz mit Cake und Zend beschäftigt. Zend fand ich eklig und von Cake war ich zwar nicht wirklich begeistert aber man konnte damit arbeiten...
Inwiefern das dann besser oder schlechter ist als Symfony kann ich aber wirklich nicht sagen, das Hauptproblem (die PHP-Basis) hat man damit natürlich nicht behoben.
Es reizt mich natürlich auch irgendwie mal ernstere Projekte mit Python zu bauen, vor allem schon weil ich solche Späße wie 1 == '1' langsam derartig satt habe, aber auch weil es doch einige Sachen gibt die in Python auf einfache Art unheimlich Aufwand sparen.
#1330: 01.Sep.2009 05:09 von fwolf
Naja .. letztlich kann man sich auch ein eigenes Framework basteln. Ich empfinde Cake, aber vor allen Dingen Symfony immer so als "mit Kanonen auf Spatzen schießen" - viel zu generalisiert und fett für meine Zwecke (d.h. also auch die meiner Kunden). In letzter Zeit verwende ich daher einerseits ganz massiv WordPress - ab Version 2.7 aufwärts wirds angenehm, damit zu arbeiten (als Programmierer) - sowie meine eigenen kleinen Spezialanfertigungen, die mit wenigen Klassen auskommen, faktisch aber auch nichts anderes als ein CMS-Framework nach dem MVC-Design Pattern darstellen.
Und wenn ich mal wieder mehr Zeit habe - so ab Mitte Oktober - hoffe ich, dass ich mich wieder mehr mit Habari als Framework beschäftigen kann. Ist um einiges schlanker und optimierter im Vergleich zu dem, was da sonst noch so rumgeistert in Sachen PHP-basierte CMS-Frameworks.
cu, w0lf.
#1331: 01.Sep.2009 07:09 von Dr. Azrael Tod
Naja, bei Projekten in der Größenordnung von seto-social würde ich jedenfalls die Kanonen-Metapher nicht wirklich anwenden. Im Gegenteil, immer wieder stellt man fest dass das Framework in der einen oder anderen Richtung nicht ganz so leistungsfähig ist wie man es eigentlich bräuchte, z.B. bei Symfony dass Forms etwas dynamischer configurierbarer sein sollte und zu viel Code benötigt, dass FunctionCache nur von FileCache abgeleitet ist statt von sfCache (und somit nicht direkt mit anderen Caching-Engines wie Memcached zusammen arbeitet ohne dass man sich seine neue Variante selbst baut) oder dass man die Funktion die ein stinknormales javascript-code-tag ausgibt gerne umbauen würde, so dass sie den Code noch durch minify jagt bevor sie ihn zurückgibt.
Natürlich kann man alles auch per Hand machen oder eine Wordpress-Instanz anpassen bis man sein Ziel erreicht. Ich finde jedoch dass ein wirkliches Framework erhebliche Vorteile beim Funktionsumfang bietet und dass es schwer wird Wordpress so zu erweitern ohne tief in seinem Code rumzuwühlen. Bei Symfony können wir nach all unseren Anpassungen noch immer einfach ein Symfony-Update einspielen indem wir die libs austauschen.
Natürlich ist Arbeitsspeicherverbrauch ein Problem... imho jedoch noch kein so extremes wie irgendwann festzustellen dass man die verwendete Platform selbst zu mehr als der Hälfte umgeschrieben hat und so massiv Aufwand an Dinge verschwendet hat die man nicht braucht.