Sapphire

Permanent Link: Sapphire 29. Dezember 2008 Comment keine kommentare

Wie schon angekündigt, habe ich mit dem Umstieg auf Netbeans begonnen, Sapphire komplett neu zu schreiben. Der eigentliche Kern ist nahezu fertig und die ersten Module in Arbeit – ging alles wesentlich schneller als erwartet. Daher werde ich Ruby nicht mehr weiter entwickeln und die bestehenden Module umschreiben.

Dinge, wie die Mandanten-Fähigkeit noch in Ruby zu integrieren, obwohl sie im Sapphire-Kern schon implementiert sind, ist sinnlos. Außerdem ermöglicht es die neue Struktur wesentlich schneller und besser, Änderungen am Hauptsystem vorzunehmen. Das Portieren der Ruby-Module sollte relativ schnell und unproblematisch laufen.

Die wichtigsten Unterschied zwischen Ruby und Sapphire:

  1. Sapphire ist durchgängig objektorientiert, soweit es PHP 5 ermöglicht.
  2. Es werden ausschließlich Prepared SQL Statements über MySQLi oder PDO unterstützt.
  3. Die Fehler-Verwaltung läuft komplett über Exceptions (SPL und eigene).
  4. Bessere und nun vollständige Implementierung des MVC-Patterns.
  5. Alle Singleton-Patterns wurden entfernt.
  6. Mandantenfähig von Anfang an.
  7. Abstraktionsebene aller Superglobals.
  8. Alle assoziativen Arrays wurden durch Instanzen der Klasse Data ersetzt.
  9. Kleinere Änderungen an der Datenbank, u.a. für die Mandantenfähigkeit. (Ein Import-Script wie von Version 1 auf 2, ist nicht nötig.)

Insgesamt bin ich mit bisherigen Stand sehr zufrieden. Vieles ist im Vergleich zu Ruby einfacher geworden, ganz besonders der Modul-Manager – bei gleichem Funktionsumfang braucht er nur knapp die Hälfte des Quelltexts. Es ist nun wesentlich einfacher, zu überprüfen, ob ein Modul schon geladen ist und an dessen Funktionen heran zu kommen. Zusammen mit einem zukünftig implementierten Observer-Pattern und der Factory des Kerns, ist das die neue Modul-Schnittstelle.

Ruby Alpha 3

Permanent Link: Ruby Alpha 3 14. September 2008 Comment keine kommentare

Änderungen gegenüber der Alpha 2:

  • Klasse Config:
    1. Methode delVar() entfernt
    2. Methode delete() hinzufügt:
      Vereinheitlicht das Namensschema und ist in der Lage mehrere Konfigurationsvariablen auf einmal zu löschen.
    3. Magische Methode __toString() implementiert.
      Gibt alle gespeicherten Konfigurationsvariablen mittels print_r() zurück.
    4. Magische Methode __get() gibt nun eine Fehlermeldung zurück, wenn auf eine nicht verfügbare Konfigurationsvariable zugegriffen wird.
    5. Konfigurationsvariablen ScriptName, ScriptDir, ScriptRoot, ScriptURL, TemplateDir, TemplateURL, TemplateName, TemplateDateFormat, TemplateTimeFormat und TemplateDateTimeFormat wurden in die Unterobjekte script und template der Klasse Data zugeorndet. Die Präfixe Template und Script entfallen. Außerdem beginnen die Eigenschaften alle mit Kleinbuchstaben.
  • Klasse MySmarty:
    1. Es ist nicht länger notwendig, die Smarty-Methoden assign() und assign_by_ref() zu verwenden, um Smarty Variablen zuzuweisen. Stattdessen wird über die magischen Methoden __get() und __set() dem Smarty-Objekt der entsprechende Wert übergeben.
    2. Magische Methoden __get(), __set(), __isset() und __unset() implementiert.
      Ermöglichen og. Vereinfachungen, um Smarty mit Variablen zu füttern.
  • Vereinheitlichtes Namensschema aller Konfigurationsvariablen entsprechend og. Änderungen zu Kleinbuchstaben am Namensbeginn.
  • Vereinheitlichte Klassennamen im Core-System.
  • Datenbankschnittstelle über PDO hinzugefügt, Ausnahmen werden über die Klasse PDOException statt DbException gehandhabt.
  • Die verfügbaren Datenbankschnittstellen MySQL, MySQLi und PDO lassen sich über die Konfigurationsdatei anwählen.
  • Markup-Vereinfachungen im Standard-Layout
  • Update auf Smarty 2.6.20 und jQuery 1.2.6
  • Anpassungen aller Klassen und Templates an das neue Namensschema und Smarty-Variablen-Handling.
  • Funktion json_encode() wird hinzugefügt, falls PHP 5.2 ohne JSON-Erweiterung kompiliert wurde.
  • Grundsätzliche Funktionalität, um falsch als Spam oder Ham erkannte Kommentare an Akismet zu melden.
  • Weitere kleine Optimierungen und Vereinfachungen der Core- und Modul-Klassen.

Geplante Änderungen bis zur ersten Beta-Version:

  • Wegfall der normalen MySQL-Schnittstelle und Unterstützung für MySQL 4.1.
  • Absicherung über vorbereitete SQL-Abfragen mittels der Methode prepare() von MySQLi bzw. PDO.
  • Namespaces für den Core und die Module, sofern PHP 5.3 verfügbar ist.
  • Admin-Bereich für Kategorien/Tags, Kommentare, Bilder, Texte und Konfigurations-Verwaltung.
  • Neues Tag- und Kategorie-Handling im Admin-Bereich.
  • Spam-Schutz ohne Akismet und Captchas.
  • Module Texts und Images implementieren.
  • Multi-Weblog-Unterstützung über mehrere Domains hinweg.
  • json_encode() durch Zend_Json_Encoder::encode() ersetzen.

Singleton mit PHP 5

Permanent Link: Singleton mit PHP 5 15. August 2008 Comment kommentare (5)

Singleton ist ein sog. Design Pattern, zu Deutsch Entwurfsmuster. Einfach gesagt, sind es Standardlösungen für bestimmte Problemstellungen innerhalb der objektorientierten Programmierung, die immer wieder auftreten.

Eines der einfachsten Muster ist das Singleton. Es stellt sicher, dass von einer Klasse nur eine Instanz erzeugt werden kann und keine weitere. Bei bestimmten Objekten, z.B. für die Datenbank-Verbindung, kann das sehr hilfreich sein. Da ein Singleton über eine statische Methode aufgerufen wird, ist es außerdem möglich dieselbe Instanz einer Klasse ohne Probleme überall im Script aufrufen zu können – widerrum sehr nützlich bei Datenbanken.

So sieht in Singleton in PHP 5 aus:

class Demo {
		
	/**
	 * @access private
	 * @static
	 * @var object
	 */	

	private static $instance = null;

	/**
	 * Singleton
	 *
	 * @access public
	 * @static
	 * @return object self::$Instance
	 */
	
	public final static function getInstance() {
		
		if(self::$instance === null) {
			self::$instance = new self();
		}
		
		return self::$instance;
	}

	/**
	 * Constructor
 	 *
	 * @access private
	 */
	
	private function __construct() {
		#Code	
	}
	
	/**
	 * No Clone Wars
 	 *
	 * @final
	 * @access private
	 */	
	
	private final function __clone() {
	
	}
	
	#Code
}

Zuerst wird das statische Attribut $instance als null definiert, gefolgt von der statischen Methode getInstance(). Die überprüft, ob in self::$instance bereits eine Instanz der Klasse hinterlegt ist. Falls nein, wird ein neues Objekt erstellt und die Referenz in self::$instance gespeichert. Anschließend gibt getInstance() die Instanz der Klasse zurück.

Wichtig ist, dass der Konstruktor der Klasse als private definiert ist. Somit ist sichergestellt, dass nur getInstance() ihn aufrufen kann und man keine weiteres Objekt der Klasse erzeugen darf. Ebenso muss die Methode __clone() als private deklariert werden, damit das Objekt nicht kopiert werden darf.

Mit folgendem Code erhält man nun die Instanz der Klasse:

$demo = Demo::getInstance();

Dieser Aufruf funktioniert überall, sobald die entsprechende Klasse eingebunden wurde.

Das Singleton Pattern ist aus diversen Gründen recht umstritten. Viele sind der Ansicht, dass man es gar nicht bräuchte. Das mag vielleicht in der normalen Anwendungsentwicklung zutreffen, aber für Web-Programmierung mit PHP, ist es insbesondere bei Datenbank-Verbindungen sinnvoll. Gerade Anfänger begehen oft in dieser Hinsicht, da die alte MySQL-Schnittstelle verwendet und auf die Verwaltung der einzelnen Verbindungen zum Datenbank-Server gepfiffen wird. Eine DB-Klasse mit Singleton stellt sicher, dass es nur eine Verbindung gibt und das entsprechende Objekt überall verfügbar ist.

Hinweis: aufgrund der mangelhaften Objekt-Unterstützung in PHP 4, ist ein Singleton dort – in der oben gezeigten. Form – nicht möglich.