Angetrieben durch die Tatsache, dass keines der OpenSource Systeme mich wirklich zufrieden gestellt hat und meine Anforderungen abdecken konnte, hatte ich mich dazu entschieden mir selbst eines zu schreiben.

Zur Zeit verwende ich Collabtive. Das war das Beste, was ich finden konnte, aber wirklich glücklich macht es mich auf Dauer auch nicht.

Ich habe nun einige Zeit damit verbracht über das Framework nachzudenken. Und hatte mich letztendlich für Symfony2 entschieden. Warum? Das Zend Framework 1 ist praktisch deprecated, dennoch steht das ZF2 noch nicht als finale Version zur Verfügung. Daher fällt beides für mich flach. Ich hatte also die Wahl zwischen Symfony2, Codeigniter2, Kohana und den zehntausend kleinen Frameworks, die so im Web rumschwirren. Gegen die “kleinen” Frameworks spricht einfach die fehlende Communitygröße.
Ergo blieben Symfony2 und Codeigniter2 übrig.  Die Wahl auf Symfony viel einfach aus Sympathie-Gründen. Das Framework arbeitet mit Namespaces und das macht auf mich einfach einen moderneren Eindruck. Annsonsten geben sich die beiden Frameworks nicht viel.

Ich lese mich im Moment etwas ein und werde die nächsten Tage mal ein wenig Code in das YAP GitHub Repository pushen. Und ich werde bei Gelegenheit mal ein Konzept schreiben, wie ich mir das Ganze vorstelle.

Ähnliche Artikel

• GitHub Account ausgepackt
• Zend Framework Resourcen
• Und da ist es: Ein brauchbares PMS!

Offizielles

• framework.zend.com/manual/ Die offizielle Dokumentation. Erster Anlaufpunkt, aber oftmalt findet man hier nicht alle Infos, die man sucht oder zu wenig Beispiele.
• devzone.zend.com/tag/Zend%20Framework Offizielle Zend Developer Zone
• framework.zend.com/wiki Das ZF Wiki

Blogs

• phpdev.ro/tag/zend Anrei Gabreanus Artikel zum Framework. Der Blog ist leider inaktiv
• zf-tutorials.de Einige Tutorials zum ZF
• blog.astrumfutura.com Pádraic Brady
• weierophinney.net/matthew Matthew Weier O’Phinney
• akrabat.com Rob Allen
• codeutopia.net Jani Hartikainen
• dragonbe.com Michelangelo van Dam
• ajbrown.org A.J. Brown
• blog.fedecarg.com Federico Cargnelutt
• matthewturland.com Matthew Turland
• zfblog.de ZFBlog

Podcasts

Bücher

• survivethedeepend.com Survive The Deep (kostenloses online Buch)
• manning.com/allen Zend Framework in Action by Rob Allen
• (Amazon) Zend-Enterprise-Patterns-Experts-Voice
• apress.com/9781430218258 Beginning Zend Framework
• (Amazon ) Guide To Programming With Zend Framework

Ähnliche Artikel

• YAP: Framework-Wahl
• Den Horizont erweitern: Das Zend Framework
• Inspiration für Software-Entwickler

• Teil 1: Vorwort
• Teil 2: Installation und Konfiguration
• Teil 3: PHP
• Teil 4: Einen Tomcat anbinden
• Teil 5: Basic Authentication

Installation

# apt-get install php5 php5-cli php5-cgi php5-suhosin php5-fpm

# /etc/init.d/php5-fpm restart

# vim /etc/nginx/enable_php.inc

location ~ \.php$ {
    if (!-f $request_filename) {
        return 404;
    }

    fastcgi_split_path_info ^(.+\.php)(.*)$;
    fastcgi_pass   backend;
    fastcgi_index  index.php;
    fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;

    include fastcgi_params;

    fastcgi_intercept_errors        on;
    fastcgi_ignore_client_abort     off;
    fastcgi_connect_timeout 60;
    fastcgi_send_timeout 180;
    fastcgi_read_timeout 180;
    fastcgi_buffer_size 128k;
    fastcgi_buffers 4 256k;
    fastcgi_busy_buffers_size 256k;
    fastcgi_temp_file_write_size 256k;
}

server {
    server_name itws.de www.itws.de;
    root /var/www/itws.de/www;

    # redirection to blog.itws.de
    rewrite ^(.*) http://blog.itws.de$1 permanent;
}

server {
    server_name blog.itws.de;
    root /var/www/itws.de/blog;

    include defaults.inc;
    include enable_php.inc;
}

server {
    server_name ci.itws.de;
    root /var/www/itws.de/ci;

    include defaults.inc;
    include enable_php.inc;
}

upstream backend {
    server 127.0.0.1:9000;
}

Ähnliche Artikel

• Debian: Von Apache zu Nginx – Teil 1: Vorwort
• Wordpress unter Nginx
• Debian: Von Apache zu Nginx – Teil 5: Basic Authentication

• Teil 1: Vorwort
• Teil 2: Installation und Konfiguration
• Teil 3: PHP
• Teil 4: Einen Tomcat anbinden
• Teil 5: Basic Authentication

In diesem und den folgenden Beiträgen (es gibt jeden Tag einen) berichte ich euch ein wenig über meine Migration von Apache zu Nginx. Es war eigentlich nicht beabsichtigt, dass da ganze fünf Beiträge draus werden, aber irgendwie wurde es doch ziemlich viel Text und das war dann für einen einzelnen Artikel etwas zu viel. Da könnte man ja fast den Eindruck bekommen, ich würde gerne schreiben … Keine Angst, das einzige was ich gerne in großen Mengen schreibe ist Programmcode

However, ich hatte meinen VPS (Debian 6) bisher immer mit dem apache2 betrieben und auch meine Entwicklungsumgebung auf meinem Desktop und dem Notebook ebenfalls. Das hatte mehrere Gründe. Zum Einen bin ich mit dem Apache aufgewachsen und hatte eigentlich nie etwas anderes verwendet. Ich war auch immer sehr zufrieden mit dem Apachen. Es ist ein guter Webserver mit einer großen Auswahl an mächtigen Modulen und er ist sehr leicht zu konfigurieren. Da ich aber ab und an gerne etwas Neues ausprobiere und immer Spaß daran habe, an meinem Server zu schrauben (auf Software-Ebene), wollte ich mal einen anderen Webserver ausprobieren. Genaugenommen war das Projekt yaana.de einer der Auslöser. Ich möchte da noch etwas Performance aus dem Server quetschen. Und dafür sollte ich mich zu allererst vom Apachen verabschieden.

Zur Auswahl stehen also – neben dem Apachen – Lighttpd und Nginx (ausgesprochen: engine-x).

Zu allererst ein kurzer Überblick der Vor- und Nachteile der drei Kontrahenten: Apache, Lighttpd und Nginx:

Der Apache

Vorteile

• Open Source & Kostenlos
• Community. Apache ist der am meist verbeiteste Webserver, die Community dahinter ist entsprechend gigantisch.
• Module. Es gibt unzählige Module für den Apache um praktisch jede Funktionalität abzudecken

Nachteile

• Performance. Der Apache ist um einiges langsamer als seine Konkurenten. Vor Allem wenn es um das Ausliefern von statischen Dateien geht.
• Stabilität. Der Webserver hat schon mit schwachen DoS/DDoS Attacken Probleme, der Arbeitsspeicher (und das Logverzeichnis) verbrauchen innerhalb kurzer Zeit viel Speicher.
• Veraltet und überfüllt. Außerdem ist die Standard Konfiguration meistens nicht optimal und muss angepasst werden.
• Die Entwicklung läuft vergleichsweise langsam.

Der Lighttpd

Vorteile

• Open Source & Kostenlos
• Leichtgewichtig. In Version 1.4.13 benötigt der Lighty nicht mehr als 2Mb RSS auf einem VPS. Ein einzelner Prozess erledigt alles, selbst wenn 100 Connections eingehen.
• Geschwindigkeit. Die Auslieferung von statischen Dateien geschieht mit einer unglaublichen Geschwindigkeit. Das FastCGI und das Proxy Serving ist ebenfalls rasant schnell.
• Module. Es gibt gefühlt unendlich viele Module mit einer guten Dokumentation.
• Mod_magnet ist eine Scripting Engine direkt im Webserver. Das Modul integriert Lua in lighttpd.
• Community. Einen Blog, ein Wiki/bug tracker und ein Forum. Hier findet man immer Hilfe

Nachteile

• Geringe Stabilität gerade was HTTPS+Proxy in Kombination mit Python oder Ruby angeht.
• Kein Mod_rewrite. Die Built-in rewriting engine ist Schrott, und das Portieren der Apache mod_rewrite Regeln ist nicht ganz einfach.
• Memory leaks. Und diese wurden seither nicht gefixed.
• Die Entwicklung läuft vergleichsweise langsam.

Nginx

Vorteile

• Open Source & Kostenlos
• Leichtgewichtig. Zwar nicht ganz so leicht wie der Lighty, aber dennoch nicht so Ressourcenhungrig wie der Apache.
• Schnell. Einie benchmarks haben gezeigt, dass Nginx deutlich schneller ist als der Lighty und der Apache. Gerade was die Auslieferung von statischen Inhalten angeht.
• Module. Ähnlich wie bei den beiden anderen Kontrahenten gibt es auch hier mehr Module als man benötigt. Während Lighttpd eine Lua scripting engine besitzt, kann man den Nginx mit dem Perl Interpreter aufmotzen.
• Besseres Rewrite Modul. Ein sehr viel besseres Rewrite Modul als Lighttpd mit komplexen Bedinungen. Das Portieren von mod_rewrite Regeln vom Apache ist vergleichsweise einfach.
• Stabil und keine leaks. Keine Probleme bekannt.
• Sehr schnelle Entwicklung: Es gibt fast monatlich Updates
• Die Konfiguration ist einfach und übersichtlich.

Nachteile

• Kleine Community. Es gibt einen IRC und ein Wiki. Dann wirds auch schon eng.
• Nginx kann keine FastCGI Prozesse erstellen. Das muss dann über einen externen fcgi spawner geschehen.

Der Lighttpd kam bei mir eigentlich nie wirklich in Frage. Das hatte zwei Gründe:

1. Ist die Konfiguration wirklich hässlich Sorry aber ich bin da etwas sensibel.
2. Weil der Lighttpd ein paar Memory Leaks hat, die seit Jahren nicht gefixt werden.
3. Hatte ich mir bereits vor längerer Zeit die Rewrite Rules vom Lighty angesehen – eher durch Zufall darauf gestoßen und dann aus Neugierde recheriert – das hat mich direkt abgeschreckt.

Also fällt auf meine Wahl auf den hochangepriesenen Nginx Proxy-/WebServer, mit dem mittlerweile rund 7% des World Wide Webs betrieben werden. Darunter high-visibility Platformen wie WordPress.com, Github, Ohloh, SourceForge, Golem.de uvm. Außerdem verspricht dieser nicht nur mehr Performance sondern auch eine einfachere Konfiguration.

Auch wenn mich der Part mit dem FastCGI Prozessen etwas nerven wird. Mal sehen vielleicht finde ich dafür ja noch eine saubere Lösung.

Anforderungen

Ich habe natürlich einige Anforderungen an den Webserver. Damit ich meinen Server migrieren kann, benötige ich folgende Funktionen:

• RewriteRules für .htaccess files
• Basic Authentication
• Virtuelle Hosts
• PHP
• Einen Proxy um den Java Webserver dahinter anzubinden

Nginx ist nicht nur ein Webserver sondern auch ein POP3/IMAP-Proxy und ein reverse Proxy. Letzteres Problem war also schonmal gar kein Thema weil der Server einfach exakt für solche Dinge designed wurde. Auch Mongrel lässt sich sehr sehr gut mit Nginx betreiben, wie ich gelesen habe.

PHP lässt sich über FastCGI anbinden, was deutlich performanter ist als mod_php für den Apachen, da PHP somit nicht bei jedem Request mitgestartet wird. Was mir hier noch etwas Sorgen bereitet, ist das nicht vorhandene Feature vom Nginx, FastCGI Prozesse zu starten. Glücklichwerweise bringt PHP5 einen eigenen FastCGI Prozess Manager mit sich: PHP-FPM. Das erleichtert die Anbindung von PHP ungemein.

Virtuelle Hosts, Basic Authtentication und RewriteRules sind für moderne Webserver ohnehin bereits Standardumfang. Und die Rewrite Rules von Nginx sehen sogar ganz brauchbar aus (wenn es um das Portieren von  mod_rewrite Regeln geht). Sollte also alles kein Thema sein.

Bleibt noch eine kleine Anforderung: Die Verzeichnis-Struktur. Meine bisherige Verzeichnis-Struktur sieht wie folgt aus:

/var/www/hostname/subdomain/

Entsprechend gibt es folgende Verzeichnisse:

• /var/www/itws.de/blog
• /var/www/itws.de/ci
• /var/www/yaana.de/www
• /var/www/yaana.de/blog

Und einige mehr.

Diese Struktur will ich natürlich beibehalten. Es hätte mich nun gewundert, wenn das nicht gehen würde. Nach kurzer Recherche, war ich mir sicher, dass das kein Thema sein wird.

Es kann also los gehen.

Ähnliche Artikel

• Debian: Von Apache zu Nginx – Teil 3: PHP
• Debian: Von Apache zu Nginx – Teil 4: Einen Tomcat anbinden
• Debian: Von Apache zu Nginx – Teil 2: Installation und Konfiguration

Für mein aktuelles Projekt entwickle ich zur Zeit einen crawler, der Websites zieht und analysiert. Natürlich bin ich da direkt auf sämtliche Encoding-Problemchen gestoßen, die man sich nur vorstellen kann und hatte unglaublich viel Spaß damit …

Ich verwende das Zend Framework und daher entsprechend die Klasse Zend_Http_Client um die HTTP-Requests abzusetzen.
Danach suche ich den Inhalt der Seite raus, sodass lediglich ein String ohne HTML-Tags und damit reinem Text übrig bleibt.
Gebe ich mir diesen nun einfach auf die Shell aus, stimmt das Encoding manchmal und manchmal nicht. Das sieht man dann immer schön an den kaputten Umlauten.

Ich möchte hier das Ergebnis meiner Arbeit mit euch teilen. Nicht erschrecken, es ist keine saubere Lösung (die sauberen Implementierungen haben allesamt nicht funktioniert). Der Code deckt auch nicht alle denkbaren Fälle ab, aber ich konnte bisher jeden beliebigen kaputten String mit deutschem Text und explodierten Umlauten in einen lesbaren String mit intakten Umlauten konvertieren. Da das mehrere 100 Texte aus verschiedensten Quellen aus dem Netz waren, behaupte ich mal, dass der Code recht brauchbar ist. Im Zweifelsfall dient er als gute Basis für eine umfassendere Implementierung.

Der Methode magicFixStringEncoding() kann man also einen beliebigen  String übergeben unabhängig davon ob er völlig in Ordnung ist oder total verstümmelt. Die Rückgabe der Methode sollte immer einen sauberen String mit funktionierenden Umlauten entsprechen.

Für Verbesserungsvorschläge bin ich jeder Zeit offen. Annsonsten viel Spaß denen, die den Code gebrauchen können

class ITWS_Tool {
	public static function magicFixStringEncoding($strInput) {
		if (preg_match('/[üäöÄÖÜß]/i', $strInput) === 1) {
			$strInput = self::convertEncoding($strInput, 'UTF-8');

			if (strlen(utf8_decode($strInput)) !== strlen(utf8_decode(utf8_decode($strInput)))) {
				$strInput = utf8_decode($strInput);
			}
		} else {
			$strInput = self::convertEncoding($strInput, 'UTF-8', 'ISO-8859-15');
		}

        return $strInput;
    }

    public static function convertEncoding($strInput, $toEncoding, $fromEncoding = '') {
        if ($fromEncoding == '') {
            $fromEncoding = mb_detect_encoding($strInput, array('UTF-8', 'ASCII', 'ISO-8859-1', 'JIS', 'EUC-JP', 'SJIS'), true);
		}

        if ($fromEncoding == $toEncoding) {
            return $strInput;
		}

        return mb_convert_encoding($strInput, $toEncoding, $fromEncoding);
    }
}

Ähnliche Artikel

• PHP 5.4 Feautre: Traits – Horizontaler Code Reuse
• Den Horizont erweitern: Das Zend Framework
• [PHP] Der include path

Netbeans hatte ich vor zwei Jahren schonmal ausprobiert, war da aber von dem Layout der Benutzeroberfläche wenig begeistert – um nicht zu sagen, sie war hässlich. Das hat sich mittlerweile geändert. Fein.

Positiv beeindruckt hat mich erstmal die Tatsache, dass es ein Git Plugin gab. Dabei sollte es aber nicht bleiben, denn das importiere Projekt hat er direkt als Git Projekt und als Zend Framework Projekt erkannt. Abgefahren. Eclipse wusste das nichtmal nachdem ich es ihm klar gemacht habe. Egal. Ich habe alle Konfig-Einstellungen, die ich benötigt habe auch direkt gefunden. Super.

Besonders gefällt mir aber die Performance. Macht richtig Spaß damit zu arbeite, wenn man Eclipse gewohnt ist. Bis die JVM das zweit mal abgeraucht ist, habe ich etwas rumgespielt. Danach war ich von Java wieder so genervt, dass ich keine Lust mehr hatte.  Dennoch bin ich von Netbeans bisher beeindruckt. Die IDE bietet also durchaus das Potential Eclipse PDT als preferierte PHP IDE abzulösen.

Nur hoffen, dass Oracle endlich mal ein wenig an der Stabilität der JVM arbeitet, denn so macht das echt keinen Spaß. Aber was will man von Java auch anderes erwarten

over and out

Ähnliche Artikel

• YAP: Framework-Wahl
• Zend Framework Resourcen
• Debian: Von Apache zu Nginx – Teil 3: PHP

Vererbung: Vertikaler Code Reuse

class A {
	public function foo() { ....}
}

class B extends A { }

Bei der objektorientierten Vererbung werden alle nicht-privaten Methoden und Attribute einer Klasse auf die Kind-Klasse vererbt. Das ist toll, denn so braucht man viele Methoden nur einmal zu implementieren, kann sie aber in vielen verschiedenen Klassen wiederverwenden. Das ist vertikaler Code Reuse. Tolle Sache, kein Thema.

Traits: Horizontaler Code Reuse

Abhilfe schaffen hier in PHP 5.4 die sogenannten Traits, welche bereits in Perl 6 oder Scala zur Verfügung stehen. Sie erlauben es dem Entwickler Behaviors (also Verhalten) in Code zu gießen. Diese Traits funktionieren im Prinzip wie Klassen können jedoch – ähnlich wie Interfaces und abstrakte Klassen – nicht instanziiert werden.

Sie sind dazu gedacht, Funktionalitäten zu gruppieren. Einer der Vorteile ist, dass eine Klasse mehrere Traits verwenden kann. Traits beheben somit einige Probleme von single inheritance Sprachen wie PHP oder Java.

Um das eben angesprochene Singleton-Pattern-Problem zu lösen genügt nun ab PHP 5.4 folgene Klassen-Definition:

trait Singleton {
    public static function getInstance() { ... }
}

class A {
    use Singleton;
    // ...
}

class B extends ArrayObject {
    use Singleton;
    // ...
}

// Beide Klassen verwenden nun das Singleton Trait und implementieren somit das Singleton-Pattern:
A::getInstance();
B::getInstance();

Es wird noch besser: Wie bereits erwähnt, kann eine Klasse kann beliebig viele Traits verwenden. Da stellt sich der aufgeweckte Coder natürlich die Frage:

Was passiert bei Konflikten?

Sprich: Was passiert, wenn zwei Traits verwenden werden, die beide eine Methode mit der selben Signatur definieren?

trait A {
    public function foo() {
        echo 'a';
    }

    public function bar() {
        echo 'A';
    }
}

trait B {
    public function foo() {
        echo 'b';
    }

    public function bar() {
        echo 'B';
    }
}

class C {
    use A, B;
}

Dazu ist folgeneds zu sagen: Traits werden bereits in einigen Sprachen verwendet und es hat sich gezeigt, dass Konflikte zwar auftreten aber das eher die Ausnahme darstellt. Dennoch muss es natürlich ein definiertes Verhalten geben, das vorschreibt, was passieren soll, wenn Konflikte auftreten.

Diese Konfliktlösung sieht hier wie folgt aus:

Erstmal wirft PHP eine Warning um dem Entwickler darauf aufmerksam zu machen, dass ein Konflikt aufgetreten ist. Und gibt dazu auch die Info, wo der Konflikt genau auftritt. In dem Fall würde es die beiden Methoden foo() und bar() melden.

Und das ist auch gut so, denn keine der beiden Methoden werden in Klasse C zur Verfügung stehen! Richtig, die Konfliktlösung sieht vor, dass alles, was einen Konflikt erzeugt, rausfliegt.

PHP zwingt uns damit, die Traits ordentlich zu verwenden und PHP zu sagen, was wir aus welchem Trait haben wollen:

class C {
    use A, B {
        B::foo instead A;
        A::bar instead B;
    }
}
?>

Dieser Code bewirkt folgendes Verhalten: Klasse C erhält aus Trait B die Methode foo() und aus Trait A die Methode bar().
Entsprechend würde ein Aufruf der beiden Methoden auf Klasse C “b” und “A” ausgeben.

Das ist zwar cool, aber dennoch nicht die sauberste Lösung. Es gibt Alternativen: So kann der Entwickler auch Aliase vergeben:

class C {
    use A, B {
        B::foo instead A;
        A::bar instead B;
        B::bar as bar2;
    }
}

Ok, ich gebe zu, dass sich die Beispiele jetzt nicht gerade durch Kreativität auszeichen, aber solange man erkennen kann um was es geht, reicht das

Klasse C würde nach diesem Beispiel nun zusätzlich eine Methode bar2() besitzen, welche der bar()-Methode von Trait B entspricht.

Fazit

Kombiniert man die OOP und ihre Features (Vererbung, Interfaces, Namespaces, Kapselung) nun mit den Traits kann man problemlos PHP-Anwendungen implementieren, die streng dem DRY-Prinzip folgen und gleichzeitg eine konzeptionell saubere Klassen-Hierarchie besitzen.

Es gibt hierzu noch ein wenig mehr zu sagen, aber das ist erstmal das Wichtigste. Alles Weitere kann ich gerne noch in einen zweiten Artikel erklären

over and out

Ähnliche Artikel

• Schei? Encoding …
• Den Horizont erweitern: Das Zend Framework
• [PHP] Der include path

Und heute habe ich dann The Bug Genie entdeckt und war sofort beeindruckt: Das Bug Tracking und Project Management System bietet eine ganze Menge an wirklich sorgfälltig implementierten Features (dazu weiter unten mehr) und das ganz ohne das System unnötig kompliziert zu gestalten. Das Open Source Projekt ist in PHP 5.3 entwickelt und nutzt alle modernen Möglichkeiten um eine wirklich sehr angenehme GUI-Erfahrung zu bieten.

Interessant sind vor Allem auch die Features, die es dem Admin erlauben Teams und Workflows (wie sieht der Ablauf aus, mit dem ein Ticket bearbeitet wird?) zu definieren.

Hier ein kleiner Auszug aus der Featureliste von TGB.

• Verwaltung von Projeten, Gruppen, Teams, Benutzern und Issues
• Definition von Workflows, Issue Fields und Issue Types
• Wiki
• VCS-Integration
• Agile development
• uvm.

Eine Detailierte Liste gibt es hier.

Einziger Nachteil ist die fehlende deutsche Übersetzung, aber das ist nur eine Frage der Zeit.

Übrigens: Im TBG Developer Blog kann man die Entwicklung des Projekts beobachten.

Das System ist also auf jeden Fall einen Blick wert, wenn jemand ein gutes Project Management System und/oder Bug Tracking System sucht. Die Installation ist eine Sache von wenigen Minuten und auch die Konfiguration des Systems geht dank der sehr benutzerfreundlichen GUI sehr gut von der Hand.

Ähnliche Artikel

• YAP: Framework-Wahl
• Zend Framework Resourcen
• Debian: Von Apache zu Nginx – Teil 3: PHP

Vor diesem Framework habe ich mich lange Zeit zurückschrecken lassen, da ich der Ansicht war, dass das nur ein Haufen sinnlos zusammengestückelter PHP Files ist und das praktische Arbeiten mit dem ZF nicht besser aussieht.

Das Framework an sich ist deutlisch komfortabler als ich dachte, das autoloading erspart viel Arbeit und die saubere objektorientierte Implementierung der Komponenten ist wirklich gut.

Bisher sieht es also ganz danach aus, als würde ich das anstehende Projekt mit dem Zend Framework umsetzen. Das hat verschiedene Konsequenzen. Zu erstmal bin ich froh, diesen Schritt getan zu haben und mich endlich mit dem Framework zu befassen. Zum Anderen wird mir das wohl auch einiges an Stoff liefern, über den ich hier im Blog schreiben kann und zum anderen kann ich endlich mal wieder ein Projekt starten und habe was zum coden. Wurde auch mal wieder Zeit.

Ähnliche Artikel

• YAP: Framework-Wahl
• Zend Framework Resourcen
• Schei? Encoding …

Dennis Becker gab folgendes Kommentar zu dem besagten Artikel auf entwickler.de ab:

PHP hat einen großen Nachteil: der Zwang, abwärtskompatibel zu bleiben. In Ruby & Python sehen ich gleich gute Alternativen, besser würde ich aber nicht sagen. PHPs Problem liegt einfach in der Vergangenheit und für die urspürngliche Kernaufgabe, für die es entwickelt wurde: Form Handling und Database Communication. Ruby & Python wurden von Anfang an mit einem viel größeren Scope entwickelt!

Meiner Meinung nach ist das der springende Punkt: Eine Anforderung an PHP ist die Abwärtskompatibilität und genau das ist auch eine Schwäche, da hier nicht nur Altlasten existieren sondern auch einige Konzepte wie eine etwas stärkere Typisierung etc. nur schwer umzusetzen sind. Dass Ruby und Python oft als bessere Sprachen angepriesen werden, liegt daran, dass diese mit anderen Anforderungen entwickelt wurden.

Meiner Meinung nach, wäre ein Fork von PHP mal ne wirklich coole Sache. In diesem Fork könnte man stärkere Typisierung implementieren, die OOP von PHP etwas ausweiten, die ganze Altlast entfernen und in der API durchgehend für Konsistenz sorgen und – ähnlich wie Ruby und Pyhton – könnte man auf einem ganz anderern Niveau ansetzen als PHP damals in seiner ersten Version. Das klingt nun etwas Wahnsinnig, aber eine solcher Fork hätte durchaus das Potential die aktuellen Favoriten in Sachen Scriptsprachen abzulösen. Vorausgesetzt man lässt die Erfahrungen aus Ruby, Python und PHP 5.3 einfliesen und lässt die historisch-bedingten Aspekte der Sprache entfallen.

Ich würde es ja selbst machen, mir fehlt nur leider die Zeit

So, das reicht an verrückten Behauptungen für einen Tag …

Ähnliche Artikel

• YAP: Framework-Wahl
• Zend Framework Resourcen
• Debian: Von Apache zu Nginx – Teil 3: PHP