Shame on me

2 Kommentare

Hier ist er also, mein Code of Shame:

function getValue($path)
{
    return eval("return \$this->xml_config->$path;");
}

Das ist eine Methode einer Config Klasse die ein SimpleXML Objekt kapselt. Irgendwann hatte ich keine Lust mehr, die einzelnen Werte der Config sicher weiterzuleiten, also hab ich diese Methode hinzugefügt. Naja .. damit hätte ich mir das Config Objekt auch sparen können x) … *shame on me*

MVC Model geht auch ohne Datenbank!

14 Kommentare

Ich möchte mal ganz kurz etwas Frust über die implementierten MVC Pattern in den ganzen Frameworks loswerden, die ich in meinem kurzen Entwicklerleben verwendet habe:
Warum wird in der abstrakten Schicht der MVC Implementierung immer davon ausgegangen, dass hinter einem Model zwangsläufig eine Datenbank liegt. Ein Model ist doch nur die Abbildung irgendwelcher Daten die wo auch immer her kommen können, oder?! Zum Beispiel können Daten aus einem HTTP Request oder einer statischen Datei kommen, richtig?!

Also wenn dann sollte es einen Mapper geben, der aus der Datenbank die Models zaubert. Aber dass das Model seine eigenen Ursprung kennt finde ich äußerst nervig, denn wenn ich dann mal ein Datenbank unabhängiges Model schreibe, muss ich alle Methoden überschreiben, die irgendwas mit der Datenbank anstellen wollen.

So. Hab ich jetzt MVC falsch verstanden oder einfach nur noch nicht die richtigen Frameworks gefunden?

Statischen Aufruf von Instanzaufruf unterscheiden … geht nicht

4 Kommentare

Gerade hatte ich die Idee mit „if(isset($this))“ zu unterscheiden, ob eine statische Method über die Klasse oder über ein Objekt aufgerufen wurde.
Beispiel:

class Foo {
    public static function bar() {
        if (isset($this)) {
            echo "i am an object. ";
        } else {
            echo "this is a static call. ";
        }
    }
}

// beispiel verwendung
Foo::bar();
$f = new Foo();
$f->bar();

Erwartet hatte ich, dass dabei „this is a static call. i am an object. “ rauskommt, das war aber nicht der Fall. In beiden Fällen wird „this is a static call. “ ausgegeben.
Das bedeutet also, dass eine statische Methode immer statisch aufgerufen wird, selbst wenn der Aufruf über ein Objekt stattfindet.

Redaxo mag ich doch nicht

14 Kommentare

Ich hab mich vor einiger Zeit mal in einem Artikel für das CMS System Redaxo ausgesprochen, aber das bereue ich jetzt!

Ich behaupte einfach mal, dass es an meiner verstärkten Arbeit mit Java und damit an meiner (wenn auch noch mickrigen) Erfahrung liegt. Kann auch sein, dass ich einfach gemerkt hab, wie angenehm und „unumgänglich“ OOP ist.
Auf jeden Fall kotz ich grad mit Redaxo ab. Leider. An für sich kein schlechtes CMS, aber dadurch das so manches fehlt, kann man damit einfach nicht arbeiten weil man ständig auf irgendwelches hässliche Zeug stößt.

An der Stelle wird man vielleicht denken: „Hey, es handelt sich hier um ein Open Source Projekt .. da kann man doch mitarbeiten und die entdeckten Mängel beseitigen!“
Meine Antwort: „Wo soll ich anfangen?“ (ADD: klingt arrogant)
Alles in eine reine objektorientierte Architektur umwandeln?
Dokumentation schreiben?
Coding Standards einführen und 50% der Addons raus schmeißen?
Die Addon-, Modul- und Template-Download Seiten mit „Features“ wie „Sortierung“, „Tagging“ oder „Bewertungssystem“ erweitern?

Hmm .. ich hab nicht so viel Zeit (ADD: wieder arrogant).
Leider hab ich noch so gut wie keine Erfahrung mit CM Systemen da ich eher der „Entwickler unter der Oberfläche“ bin (oder sein möchte?!?) … :) Von daher meine Frage:
Was verwendet ihr, wenn eine neue (±simple) Website erstellt werden soll?

EDIT: wer denkt, dass ich ein eingebildeter Arsch bin, hat vielleicht recht oder übersehen, dass ich diesen Artikel in Rage geschrieben habe .. eigentlich könnte und würde ich ihn am besten löschen, doch ich lass ihn mal bestehen um, da die genannten Punkte wirklich etwas „nervig“ sind.

private Methoden vermeiden

4 Kommentare

Ich muss zugeben, ich hab schon lange nichts mehr geschrieben. Aber dieser Blog ist weder tot noch ist es einfach nur eine „Sommerpause“. Ich bin grad am überlegen, wie ich diesen Blog neu ausrichten kann, da ich meiner Meinung nach (noch) nicht in der Lage bin, regelmäßig qualitative Beiträge zu schreiben. Mehr dazu aber wenn es dann soweit ist.

Jetzt erst einmal der Grund für diesen Post: wozu brauch man private Methoden?!
Jede private Methode schränkt Entwickler ein, die entsprechende Klasse nicht effektiv anpassen zu können. Will man kleine Details verändern ist man entweder gezwungen, die Klasse umzuschreiben (ist bei PHP möglich, nicht aber bei Java zum Beispiel) oder von dieser Klasse zu erben und die aufrufende Methode zu kopieren und umzuschreiben. Beides ziemlich doof, weil das eine die Updatefähigkeit einschränkt und bei der anderen „Lösung“ jede Menge Code dupliziert wird.
Aktuell bin ich der Meinung, man verwendet in 98% der Fälle protected anstelle von private Methoden. Und je weniger ein Methode macht – also je mehr die Funktionalität einer Klasse auf verschiedene Methoden aufgetrennt ist, desto einfacher ist es Änderungen an der Klasse elegant und schnell durchzuführen.

Anmerkung: Dieser Post ist aus aktuellem Anlass entstanden. Ich habe mich in dieses Thema nicht hineingelesen oder damit ausführlicher beschäftigt – dieser Post ist also eher als eine Art Theorie zu betrachten.

Why should a PHP skript die?

1 Kommentar

Vor einigen Tagen wurde in einigen Blogs [1][2] diskutiert, ob die Funktion/Sprachkonstrukt die() bzw. exit() sinnvoll ist, wie man sie einsetzen sollte oder ob sie eigentlich aus PHP entfernt werden kann. Hab mich dazu näher mal damit beschäftigt und möchte folgende Verhaltensweise festhalten:

Ist zum Zeitpunkt des Aufrufs von die/exit ein instantiierten Objekt vorhanden, wird noch die „__destruct()“ Methode aufgerufen. Das gilt für jedes Objekt zu diesem Zeitpunkt. Das Skript ist also noch nicht 100%ig beendet: Es kann noch Code ausgeführt werden!
Diese Tatsache wollte ich dazu verwenden, eine Exception in einem Destruktor auszulösen welche den Exit Befehl aufhebt/überspringt. Somit könnte man mit der Instantiierung eines „ExitDestuktors“ die Verwendung von die/exit komplett unterbinden und man hätte eine schöne auffangbare Exception:

class ExitDestructor{
  public function __destruct(){
    throw new Exception("immortality");
  }
}
$exitDestructor = new ExitDestructor();
try {
  die();
} catch (Exception $ex) {
  //handle exception
}

Leider hat das nicht hingehauen. Vielleicht geht es ja mit PHP 5.3+ mit einem goto Befehl x). PHP meldet auf jeden Fall „Fatal error: Exception thrown without a stack frame in Unknown on line 0„. Dieser Fehler würde übrigens auch dann auftreten, wenn ein Skript Ordnungsgemäß beendet wird, was auch nicht gewollt wäre.
» Experiment fehlgeschlagen.

Schade. Wäre ein netter „dieToExeptionWrapper“ geworden. Da sollte man sich echt Gedanken machen, wozu man die/exit überhaupt einsetzten soll. Mir ist es schon in folgenden sinnvollen Zusammenhängen über den Weg gelaufen:
1. Meta Redirect aus dem Skript heraus auslösen: die(‚<meta http-equiv=“refresh“ content=“0; URL=‘.$url.'“>‘); – Das könnte man aber auch mit einer „RedirectException“ lösen.
2. Nach dem direkten Senden einer Datei an den Browser. Danach sollte nämlich kein einziges Byte mehr gesendet/ausgegeben werden! (Davor übrigens auch nicht.)

Der zweite Punkt ist der einzige Anwendungsfall der mir eingefallen ist, bei dem eine Exception eher weniger weiterhelfen würde! Dann ist die/exit dann also doch gerettet? Oder erhebt jemand Einspruch?