Webminds Diary

Eine gute Übersicht über gängige PHP MVC Frameworks, wie das Zend Framework oder Symfony finde ihr hier : http://www.noupe.com/php/discussing-php-frameworks.html

Tags: Uncategorized // Add Comment »

Wer PHP 5.3 auf einem nicht Windows System ausprobieren möchte steht schnell vor einem Problem.Ohne Kompilierung kommt man kaum drumrum.Besonders auf eine 64 Bit System wie Mac OS X, wird dieses ein umständliches Unterfangen, da auch alle Abhänigkeiten als 64 Bit Version vorliegen müssen oder kompiliert werden müssen. Dieses Artet schnell in stundenlangen Kompilieren aus.

Ich empfehle deshalb das XAMPP Beta Paket, bis jetzt läuft es bei mir ganz gut :  http://www.apachefriends.org/de/xampp-beta.html

Tags: PHP // 2 Comments »

Freue mich schon von der Unkonferenz im September berichten zukönnen und auf viele Intressante Talks.

http://www.php-unconference.de/

Tags: Uncategorized, private // Add Comment »

Langsam aber stetig geht es auf PHP 6 zu, gestern wurde PHP 5.3 RC1 released, die meisten Neuerungen von PHP 6 sind schon in PHP 5.3 drin:

• Closures = Anonyme Funktionen
  Beispiele gibt es hier :http://blog.agilephp.com/
• Late Static Binding
• Namespaces: Leider mit einem Backslash als Namespace Seperator, warum der Blackslash gewählt wurde könnt ihr hier nachlesen : http://wiki.php.net/rfc/backslashnamespaces.

Tags: PHP // Add Comment »

Für eine mehrsprachige Seite sollte Drupal eingesetzt werden. Als Vorgabe wollten wir viele Inhalte mit selbst definierten Contenttypen abdecken können.

Die Mehrsprachigkeit kann schon ganz gut mit Drupal-eigenen Mitteln abdeckt werden, es wird aber trotzdem das Modul i18n benötigt, um die verschiedenen Sprachen voneinander abzugrenzen.

Contenttypen

Nun kommt die meiste Arbeit: die selbst definierten Contenttypen, die später in verschiedenen Übersichten verwendet werden.  Diese Contenttypen sollen und müssen zusätzliche benutzerdefinierte Eingabefelder enthalten. Dafür kommt das Modul Content Construction Kit (CCK) zum Einsatz. Es sollen auch Felder für Logos vorhanden sein, also wurde auch noch die Erweiterung imagefield und filefield benötigt. Diese benötigen auch noch das Module imageapi. Mit diesen kann man die Contenttypen schon recht gut definieren. Nur fehlen jetzt noch die Templates für die einzelnen Contenttypen.

Templates

Drupal bietet schon im Core recht einfach Möglichkeiten, um Templates zu erstellen, inklusive verschiedener Templatetypen für unterschiedlicher Contenttypen.

Die Standart Templates heißen:

page.tpl.php (Für die Seite)

node.tpl.php (Für den eigentlichen Inhalt)

Diese kommen immer zum Einsatz, wenn keine anderen Template Dateien für den speziellen Contenttypen existieren. Diese spezialisierten Template Dateien können aber sehr einfach erstellt werden:

page-contenttyp.tpl.php

node-contenttyp.tpl.php

Beispiel für einen Dateinamen einer Page Template Datei für den Contenttyp Artikel: page-artikel.tpl.php

Templatevariabeln aus CCK Felder

Jedes Feld, das mit dem CCK erstellt wird und einem Contenttyp zugewiesen wird, bekommt einen Namen, über den es im Template angesprochen werden kann, in der Form field_name. Im PHPTemplate System wird dieses Feld zu einer Variable, um genau zu sein ein zweidimensonales Array, das je nach Typ des CCK Feldes, anders aufgebaut ist.

Beispiel für ein Texteingabe Feld:

$field_name[0]['value'] //Hier steht nur der Inhalt des Feldes ohne einleitende  HTML-Tags.

$field_name[0]['view'] //Hier steht nur der Inhalt des Feldes mit einleitende HTML-Tags.

Beispiel für ein Image Feld im CCK:

$field_image[0]['filepath'] //Relativer Path zum Bild

Views

Da Drupal nur auf der Frontpage in einer View mehre Artikel anzeigt, muss noch ein Modul her, dass diese Views auch auf anderen Seiten ermöglicht. Da das recht umfangreiche Modul View auf meiner Installation nicht funktionierte,kam das recht einfach Node Type Views Modul zum Einsatz. Dieses musste aber noch angepasst werden, da es in der aktuellen Version keine Mehrsprachigkeit unterstützt.

WYSIWYG

Um das Editieren der Beiträge zu erleichtern, wurde das What you see is what you get Editor Modul installiert, da Drupal in der Standartinstallation keines mitbringt. Dieses Modul bietet Unterstützung für verschiedene OpenSource WYSIWYG Editoren. Ich habe mich für TinyMCE entschlossen und diesen nachinstalliert, da das Modul am Anfang keinen Editor mitbringt.

Fazit

Mein Eindruck von Drupal ist, dass das Core System von Drupal zu leichtgewichtig ist, es bietet viele Funktionen, die ich von einem aktuellen CMS erwarte ohne Zusatzmodule nicht. Selbst WordPress als Blogsystem kann da zum Teil mehr als Drupal, wenn WordPress auch noch eine gute Mehrsprachenunterstützung bekommt, wäre es eine Alternative zu Drupal. Ohne das CCK und ein View System ist es meiner Meinung nur beschränkt einzusetzen, es wäre wünschenswert, wenn diese Funktionen in die Standartinstallation von Drupal mit aufgenommen würden. Auch der WYSIWYG Editor müsste eigentlich in das Hauptsystem. Zusätzlich müsste der Adminbereich aufgeräumt werden, da er doch recht unübersichtlich ist, Joomla hat mit 1.5 diesen Schritt getan.

Durch die vielen Module kann ich auch nicht abschätzen, ob die Installation ein Update auf die nächste Version gut übersteht.

Tags: PHP // 1 Comment »

Jeder Browserhersteller werkelt ja zur Zeit an seinem neuen Browser, von jedem gibt es eine Beta oder Alpha Version. Safari 4.0 Beta 1, Firefox 3.1b3 (demnächst 3.5), Opera 10 Alpha und natürlich Internet Explorer 8.

Da alle Versionen eine neue Javascriptengine haben, habe ich diese mit einem Benchmark auf meinem MacBook Pro getestet, nur der IE 8 blieb außen vor da ich diesen nur Virtualisiert hätte testen können und das hätte das Ergebnis verfälscht.

Die aktuellen Release Versionen von Opera, Safari und Firefox habe ich zum Vergleich mit getestet.

Als Benchmark kam http://service.futuremark.com/peacekeeper/ zum Einsatz.

Hier die Ergebnisse:

• Safari 4.0 Beta 1200 Punkte
• Safari 3.2.1 699 Punkte
• Firefox 3.1b3 540 Punkte
• Opera 10 Alpha 423 Punkte
• Opera 9.6.4 298 Punkte
• Firefox 3.0 267 Punkt

Einen kleinen Praxistest habe ich auch noch ausgeführt und zwar die Erstellung dieses Blogbeitrags in den verschiedenen Browsern, dabei hat leider der Safari 4 versagt, da die WordPress Thickbox im Editor nicht bedienbar ist und der Editor danach auch nicht mehr bedienbar ist. Zusätzlich ist der Safari einmal beim Benchmark abgestürzt. Ich hoffe, dass dieses in den späteren Versionen behoben ist.

Das Fazit von allen drei Browsern ist, dass sie wesentlich schneller werden als ihre Vorgänger. Das Safari hängt dabei alle ab, hat aber scheinbar noch Probleme. Es ist auf jeden Fall zu begrüssen, dass Javascript schneller wird, da ja immer mehr Webanwendungen sich darauf stützen, besonders wegen des GWT.

Tags: Web // Add Comment »

Gerade auf Heise.de endeckt: ein netter Artikel wie PHP mit Java kombiniert werden kann:

http://www.heise.de/developer/PHP-Anwendungen-mit-Java-Backends-verbinden–/artikel/121998/0

Werde demnächst die dort vorgestellten Lösung testen und vergleichen, wenn ich ein Fazit habe werde ich es hier veröffentlichen.

Tags: Java, PHP // Add Comment »

Das Konzept des Object-relational Mapping, kurz ORM, ist in der Java  Welt nicht neu, in der PHP Welt bekam dieses Konzept auch immer mehr Aufmerksamkeit durch die Bibliotheken Propel und Doctrine.

Eine kurze Vorstellung von beiden:

• Doctrine
  Ist die umfangreichste Bibliothek und orientiert sich an Hibernate und implementiert die Doctrine Query Language als Datenbankunabhängige Abfragesprache. Als Konfigurationssprache für Objekte und Relationen kommt YAML zum Einsatz.

• Propel
  Nicht ganz so umfangreich wie Doctrine, es gibt keine eigene Abfragesprache, dafür ist es performanter als Doctrine. Propel benutzt XML als Konfigurationssprache, YAML ist aber über den Umweg Symphony Framework möglich.

Beide Varianten sind gute Ansätze für kleine bis mittlere Webanwendungen, nur plant man eine Anwendung, die nur leicht größer wird als eine mittlere Webanwendung, sollte es gut überlegt sein, ob man eine der beiden Bibliotheken einsetzt.

ORMs können ja auf die alte Weise auch direkt in PHP implementiert werden, was eine sehr performante Lösung ist, dieses bringt aber auch Probleme mit sich. Die meisten Implemationen von ORMs direkt in PHP, die ich kennen gelernt habe, haben  meist folgende Nachteile: die Klasse ist von der Datenbanktabelle abhängig und erst zur Laufzeit ist der genaue Aufbau der Klasse konkret bekannt. Änderungen am Datenbankschema schlagen also direkt auf die Klasse durch.  Propel und Doctrine benutzen dafür die Konfigurationsdateien, das heißt die Datenbank und die Klassen sind abhängig von den Konfigurationsdateien.

Eine Idee, die ich demnächst verfolgen werde, ist, beide Ansätze mit MDA zu kombinieren, das könnte eine perfomante Lösunge schaffen ohne die Nachteile der direkten PHP Implementation zuhaben.

Tags: PHP // Add Comment »