Programmierstil?

[T!P-TOP]

Wie nennt man den Programmierstil, der von vBulletin, Facebook und diverseren anderen Seiten verwendet wird?

Für verschiedene Webseiten einer Website werden neue Dokumente aufgerufen.
Klickt man auf login, wird eine login.php aufgerufen. Will man was suchen, wird search.php aufgerufen.

Es wird da kein FrontController verwendet, der alle Seiten über die index ableitet.

Ich sehe da nicht so ganz den Vorteil, man muss wiederkehrende Sachen immer wieder definieren. Eine eigene HTML Class macht sich dann zwar bezahlbar, aber dennoch erkenne ich keine wirklichen Vorteile?

In vBulletin Foren sieht`s so aus, als wären die Seiten einzelne Controller. Über die search.php werden alle Dinge abgeleitet, die was mit Suchen zu tun haben - ob man nun neue Beiträge, neue Themen oder neue User sucht, usw. - diese Dinge werden über search.php kontrolliert.
Über forum.php werden Beiträge, Themen und weiter Dinge, die mit dem Forum zu tun haben, aufgerufen.

Mich würde einfach interessieren wie man diesen Stil bzw. diesen Aufbau eines Projektes bezeichnet und welche Vorteile er mit sich bringt. Da ich selber immer Schwierigkeiten habe, mich für einen Stil zu entscheiden, würde ich gerne wissen, wie das die Großen ungefähr regeln.


Grüße,
Nico

 

[threadi]

Viele Wege führen nach Rom.
Und auch hierbei zum Ziel.
Die einen bevorzugen den einen Weg, die anderen einen anderen.
Jeder meint den besten oder optimalen zu haben.
Eine ultimative Lösung gibt es dafür nicht.

Welcher Weg für Dich der Beste ist, hängt von Deinen Zielen, deinen Anforderungen und deinen Fähigkeiten ab.

Kleines Beispiel:
Ich baue z.B. derzeit an einer Seite die mit dem Templatesystem Smarty beliebige Templates ermöglicht. Die Adressierung läuft immer über eine zentrale index.php an die eine ID oder ein konkreter Templatename übergeben wird. Das lässt sich dann mittels mod_rewrite auch relativ einfach zu SEO-kompatiblen URLs umformen. Der Vorteil hierbei ist, dass man alles schön zentral hat. Man schreibt alles was man braucht in nur wenige Dateien und hat dennoch ein flexibles System.

Ich hätte allerdings auch für jede Ansicht, jedes Template eine eigene Datei verwenden können. Eine index.php für die Startseite, eine rubrik.php für die Rubrik "Rubrik". Über passende mod_rewrite-Anweisungen kann man auch das SEO-kompatibel gestalten. Der Vorteil hierbei ist, dass alle Seiten unabhängig voneinander sind. Eine Änderung an einer Datei beeinflusst für den Moment nicht die anderen Dateien. Außer man ändert an zentralen Funktionen z.B. zur Templatedarstellung etwas, was aber nur am Anfang der Webseitenentwicklung geschehen sollte.

Es ist gut, wenn Du dir die verschiedenen Möglichkeiten anschaust. Aber Du musst für dich den optimalen und für dich geeigneten Stil selbst finden.

 

[T!P-TOP]

Der einzige Vorteil liegt also in der Unabhängigkeit?
Mir ist aufgefallen, dass dieses ableiten über die index.php bei Login geschützten Seiten ein paar Nachteile mit sich bringt. Rufe ich eine interne Datei (z.B. profil.php) auf, muss ich in diese einen Schutz einbauen, damit diese Seite nicht "alleine" aufgerufen werden kann. Weil wenn man nicht im System eingeloggt ist, sollte man ja nicht die profil.php aufrufen können.

Das heißt, obwohl ich alles über die index.php ableite, und dort überprüfe ob eine Session registriert wurde, muss ich dennoch in allen Datein erneut prüfen, ob eine Session vorhanden ist, damit die Datein nicht einzeln aufgerufen werden können. Somit könnte ich mir gleich sparen, alles in die index.php einzubinden (includen), da ich die Session so oder so in allen Datein überprüfen muss.

Alles über die index.php abzuleiten ist eigentlich nur dann sinvoll, wenn man ohne Session arbeitet, oder sehe ich das falsch?

 

[threadi]

Siehst Du teilweise richtig. Die index.php könnte man natürlich für das öffentliche Web nutzen. Für passwortgeschützte Bereiche könntest Du eine andere Datei verwenden und in dieser (und auch nur in dieser) die nötigen Prüfungen einbauen. Das ist quasi ein Zwischending aus den beiden von mir oben beschriebenen Möglichkeiten (neben denen es noch viele andere gibt).

 

[mermshaus]

Wahrscheinlich ist es klar, aber auch für Mitlesende: Ein URL sagt grundsätzlich absolut nichts über das verarbeitende Script aus. Ein Aufruf von example.com/blub/blab/blob/profile.php kann problemlos von einem Script /index.php abgearbeitet werden (→ Rewriting). URLs sind keine Entsprechungen zu einer physischen Verzeichnisstruktur auf dem Server.

Ich bin ein Verfechter von FrontController-Layouts (eine index.php) statt „Include“-Layouts (jede Scriptseite inkludiert redundant die wichtigsten Dateien).

Letztlich ist der Unterschied jedoch gar nicht so groß. Auch ein FrontController-Design ruft üblicherweise spezielle Unterdateien/-klassen auf, die die tatsächliche Logik enthalten. Genauso muss ein Include-Design (Mehr-Seiten-Design? – keine Ahnung) zentralen Code einbinden, der immerzu ausgeführt wird.

Ich vermute, viele Systeme, die auf Einzelskripte setzen, sind vor allem historisch so gewachsen.

 

[crash]

Ausschließlich sind diese so gewachsen.

Alles einzeln zu inkludieren ist einfach unflexibel. Man kann schwieriger Code entfernen und Refactoring betreiben. Ein Autoloader lädt auch wirklich nur das was man braucht und nicht was ich versehentlich inkludiert habe.

 

[T!P-TOP]

Ich bin ein Verfechter von FrontController-Layouts (eine index.php) statt „Include“-Layouts (jede Scriptseite inkludiert redundant die wichtigsten Dateien).

Wenn ihr von Einzelscripts redet, meint ihr zB, dass die login.php aufgerufen wird, wenn man sich einloggen möchte, oder ein register.php, wenn man sich registrieren möchte und diese Datein werden nicht in eine umfassende Datei, wie main oder index.php eingebunden, sondern alleine aufgerufen?

Ich überlege mir gerade, wie ich für Passwort geschützt Seiten ein möglichst flexibles System bauen kann, wobei ich auf Einzelscripte setzten möchte:

Im Prinzip muss man ja auf jeder Einzelseite nur eine Datei includen/einbinden. Diese Datei enthält die autoloader Funktion, welche Klassen oder Interfaces aus einem /inc/ oder /lib/ Verzeichnis holt.

Rufe ich nun auf der login.php oder register.php die HTML:rintBody(); Methode auf, die mir einfach nur </head><body> ausgeben soll, holt __autoload() die HTML Klasse und somit habe ich auf deren Methoden Zugriff? Somit werden auf jeder einzelnen Scriptseite nur die Dinge inkludiert, die man wirklich braucht - wodurch man ja wiederum Ladezeiten bzw. Serveranfragen einsparen kann!?

Einen FrontController muss bzw. kann man ja bei Einzelscripts auch einsetzen. Rufe ich in vBulletin auf forum.php ein Forum auf, soll ein Modul eingebunden werden, welches sich für den gewählten Forenbereich kümmert. Erstelle ich nun ein Thema, wird ein Request ausgeführt, also eine action - also FrontController kommen ja bei Einzelscripten genau so zum Einsatz, oder nich?

Wenn bei forum.php ein Thema/Thread oder eine Forenabteil ein modul ist, was ist dann forum.php selbst?


Wenn schon da n Thread offen is, werde ich gleich noch ne Frage los:
Was nützen einem Setter und Getter Methoden? Eigenschaften/Attribute, die auf private gesetzt sind, sind für das Objekt sichtbar, das hat der Entwickler so entschieden - nur das Objekt muss auf diese zugreifen können, da diese nur für das Objekt von Bedeutung sind. Wenn man aber Eigenschaften eines Objektes von außen verändern oder deren Werte bekommen möchte, braucht man ja die Attribute nur auf public setzten. Ich mein, wenn man Getter und Setter Methoden verwendet, um private Inhalte nach außen zu tragen, ist das doch ein Wiederspruch?

Wenn ich privaten Klassenattributen einen Wert zuweisen möchte, kann ich das genau so gut über den Konstruktor tun, anstatt für jedes private Attribut eine setter Methode zu schreiben.

Vielen Dank im Vorraus für eure Antworten!

Grüße
Nico

 

[struppi]

Ich glaube das ist ein Problem, dass vor allem PHP Entwickler haben, da es dort keine Unterscheidung zwischen einem Skripte und einem Modul gibt. Ein Skript, dass zu einem späterem Zeitpukt eingebunden wird ist ein Modul, dass für sich allein nicht lauffähig sein sollte. Am besten ist es, wenn die Module ausserhalb des über http erreichbaren Bereich liegen. Die Rechteverwaltung läuft natürlich über den Frontcontroller.

autoload Funktionen sollten sparsam eingesetzt werden, da diese i.d.R. langsam sind. Ein klares Konzept ist flexibler und sicherer, als zuviel Automatismus. Ich halte es für sinnvoller, die Aktionen in einem zentralen Objekt zu speichern (das vom FC initiert wird) und die für die Anwendung notwendigen Eigenschaften dort abzufragen.

Du musst ja nicht nur daran denken, wie der geschützte Bereich aufgerufen wird, sondern du möchtest vielleicht auch einen Link auf diesen Bereich erzeugen, aber nur, wenn der Benutzer die Berechtigung dazu hat. Dafür brauchst du eine ActionMap, die einerseits alle Funktionen kennt und anderseits auch den Status des Users.

Setter/Getter finde ich manchmal auch übertrieben, aber der Gedanke dahinter ist, dass der Wert eines privaten Attribut, dass von aussen verändert werden kann, überprüft wird.

 

[T!P-TOP]

OK, danke struppi.


Nun werde ich noch beschreiben, wie ich ein Projekt aufbauen würde und vielleicht könnt ihr mir dann bitte sagen, ob das von der Umsetzung gut ist und/oder was man besser machen kann/sollte/muss.



Nehmen wir an, ich möchte eine kleine Community programmieren. Man soll ein eigenes Profil besitzen und man kann Private Nachrichten an andere User verfassen oder welche lesen.


Datein und Verzeichnisse:
index.php
home.php
login.php
messages.php
profile.php
+module
|- editprofile.php
|- viewprofile.php
|- sendmessage.php
|- viewmessage.php



Die index.php ist die Startseite von dem ganzen Projekt. In der index.php befindet sich lediglich ein Formular für den login. Die Daten, die man in das Formular eingibt, werden an login.php geschickt. Sind sie richtig, gibt es ein weiterleitung auf die home.php - die Startseite im internen Bereich. Ist der Login fehlerhaft, bleibt man auf der login.php, wo ein Login Formular zu sehen ist mit einer Fehlermeldung.
Ist man eingeloggt, kann man nun andere Profile oder das eigene ansehen. In beiden Fällen wird profile.php aufgerufen, in dieses wiederum wird ein Modul reingeladen (viewprofile.php). In diesem Modul wird geprüft, welches Profil man sich ansieht, ist es das eigene, sieht man alle Profildaten und einen Bearbeiten Button, andernfalls sich man das öffentliche Profil eines Nutzers.
Ist es das eigene und klickt man auf der Bearbeiten Button, wird anstatt dem viewprofile.php-Modul das editprofile.php-Modul eingebunden. In diesem Modul gibt es einfach ein Formular, über das man die Profildaten editieren kann.
Im Internen Bereich gibt es nun noch die Privaten Nachrichten. Klicke ich nun diesen Menüpunkt an, wird messages.php aufgerufen. Wenn ich nun eine Nachricht lese, wird viewmessage.php eingebunden, schreibe ich eine Nachricht, wird das Modul sendmessage.php eingebunden.


Wenn aber editprofile.php und sendmessage.php Module sind, was sind dann sogenannte actions?

Wie soll ich auf den einzelnen Scripten prüfen, ob eine Session registriert wurde? Soll ich da eine einzelne Funktion aufrufen, oder einfach nur eine Datei einbinden in welcher eine if-Bedingung ist, welche im Falle eines trues einem zur login.php weiterleiten?

Oder ich lege eine class.Security.php an:
In der kann ich alles was mit security zum tun hat definieren. Da kann ich zB eine statische Methode namens escape anlegen, welche einfach dann mysql_real_escape_string() ausführt. Oder eine Methode namens printLoginForm - die gibt einfach ein Login Formular aus (das kann ich dann auf der index.php und der login.php nutzen). Außerdem gibts ne Methode, die die login Daten prüft und den User bei richtiger Kombination auf die home.php weiterleitet.
Ansonsten noch eine weiter Methode zum überprüfen der Session -> ist eine vorhanden, gibts keine Veränderungen, andersfalls wird man zur login.php geschickt.

Mir gehts es hier nur mal um die ungefähre Strukturierung bzw. hierarchisierung von Projekten, vorallem im Einsatz von Einzelscripten.



Grüße
Nico

 

[T-sneak]

Hallo, also das mit den Getter und Setter kommt ja aus anderen Programmiersprachen, das ganze bietet dir den Vorteil das du die Werte vorher überprüfen kannst z.B.
setZahl($zahl).. dann kannst du z.B. noch testen ob die zahl in einem bestimmten Bereich liegt. Sprich du kannst die Gültigkeit noch überprüfen bevor du eine Variable fest legst. Das ergibt zwar nicht soviel Sinn bei eigenen Sachen aber stell dir vor andere Entwickler wollen deine Klasse nutzen die keine Ahnung haben was die einzelnen Variablen machen und welche Werte gültig sind, diese würden die Funktionsweise der Klasse vlt Sogar kaputt machen. Als Beispiel hätte ich die Klasse Mathek, wenn du mit dieser eine Wurzel ziehen willst von einer Variable die negativ ist hast du ein Problem und sowas kannst du mit getter und setter vermeiden.

 

[mermshaus]

Setter/Getter finde ich manchmal auch übertrieben, aber der Gedanke dahinter ist, dass der Wert eines privaten Attribut, dass von aussen verändert werden kann, überprüft wird.

Genau. Und der Gedanke dahinter ist, dass das Objekt jederzeit in einem „gültigen“ oder „definierten“ Zustand ist.

Nimm an, du hast eine Klasse Circle mit einer Instanzvariable radius und einer Methode getArea(), die die Kreisfläche zurückliefert.

Wäre radius eine öffentliche (public) Instanzvariable, könnte etwa per $circle->radius = -1; ein ungültiger Wert zugewiesen werden. Beim Aufruf von Methoden wie getArea() müsste nun immer einzeln geprüft werden, ob der Status des Objekts (in diesem Fall die Zusicherung, dass der Radius positiv ist) korrekt ist, bevor die eigentliche Funktionalität ausgeführt wird.

Setter unterstützen zudem Type-Hinting, stellen also sicher, dass nur eine Instanz einer bestimmten Klasse übergeben werden kann.

Und Getter/Setter gestatten es, nur Lese- oder nur Schreibzugriff zu ermöglichen.

Komplettes Beispiel mit Circle und Cylinder:

<?php

abstract class GeometryObject2D
{
    abstract function getArea();
}

abstract class GeometryObject3D
{
    abstract function getVolume();
}

class Circle extends GeometryObject2D
{
    /** @var float */
    protected $radius;

    /**
     *
     * @param float $radius
     */
    public function __construct($radius = 1.0)
    {
        $this->setRadius($radius);
    }

    /**
     *
     * @return float
     */
    public function getRadius()
    {
        return $this->radius;
    }

    /**
     *
     * @param float $radius
     */
    public function setRadius($radius)
    {
        if (!is_float($radius) || $radius <= 0) {
            throw new InvalidArgumentException(
                    'radius has to be a float > 0');
        }

        $this->radius = $radius;
    }

    /**
     *
     * @return float
     */
    public function getArea()
    {
        return (M_PI * pow($this->radius, 2));
    }
}

class Cylinder extends GeometryObject3D
{
    /** @var Circle */
    protected $bottomArea;

    /** @var float */
    protected $height;

    /**
     *
     * @param Circle $bottomArea
     * @param float $height
     */
    public function __construct(Circle $bottomArea, $height = 1.0)
    {
        $this->setBottomArea($bottomArea);
        $this->setHeight($height);
    }

    /**
     *
     * @return Circle
     */
    public function getBottomArea()
    {
        return $this->bottomArea;
    }

    /**
     *
     * @param Circle $bottomArea
     */
    public function setBottomArea(Circle $bottomArea)
    {
        $this->bottomArea = $bottomArea;
    }

    /**
     *
     * @return float
     */
    public function getHeight()
    {
        return $this->height;
    }

    /**
     *
     * @param float $height 
     */
    public function setHeight($height)
    {
        if (!is_float($height) || $height <= 0) {
            throw new InvalidArgumentException(
                    'height has to be a float > 0');
        }
        
        $this->height = $height;
    }

    /**
     *
     * @return float
     */
    public function getVolume()
    {
        return ($this->bottomArea->getArea() * $this->height);
    }
}



$circle = new Circle(2.0);
var_dump($circle->getArea());

$cylinder = new Cylinder($circle, 5.0);
var_dump($cylinder->getVolume());

Wenn ich nichts übersehen habe, ist es nicht möglich, eines der Objekte in einen Zustand zu versetzen, der keinen Sinn ergibt.

 

[mermshaus]

Wenn aber editprofile.php und sendmessage.php Module sind, was sind dann sogenannte actions?

Ich würde spontan sagen: Nach meiner Definition wären die beiden Dinge Actions. editprofile.php wäre die „edit“-Action eines „profile“-Controllers, sendmessage.php wäre die „send“-Action eines „message“-Controllers.

Ein Modul ist nach meiner Definition ein Zusammenschluss verschiedener Controller und Models zu einer größeren Sinneinheit. Ein Blog-Modul kann etwa einen Blog-Controller besitzen, der die einzelnen Einträge darstellt und Kommentare entgegennimmt, und einen Archive-Controller, der ein Archiv darstellt, und einen Admin-Controller, der ein Backend zur Administrierung bereitstellt.

Diese Auslegung mag aber stark von „üblichen“ FrontController-/MVC-Ansätzen wie dem das Zend Frameworks geprägt sein.

- Zend Framework

Hier habe ich mal ein simples Beispiel für eine MVC-Architektur aufgeschrieben.

- MVC

Wie soll ich auf den einzelnen Scripten prüfen, ob eine Session registriert wurde? Soll ich da eine einzelne Funktion aufrufen, oder einfach nur eine Datei einbinden in welcher eine if-Bedingung ist, welche im Falle eines trues einem zur login.php weiterleiten?

Das ist im Grunde egal. Aber hier siehst du, dass du die entsprechende Logik redundant auf praktisch jeder Seite eintragen musst. Das heißt, der notwendige Code muss in einer Datei stehen, die von jedem Einzelskript eingebunden wird.

Oder ich lege eine class.Security.php an:
In der kann ich alles was mit security zum tun hat definieren. Da kann ich zB eine statische Methode namens escape anlegen, welche einfach dann mysql_real_escape_string() ausführt. Oder eine Methode namens printLoginForm - die gibt einfach ein Login Formular aus (das kann ich dann auf der index.php und der login.php nutzen).

Das sind zu viele zu unterschiedliche Zuständigkeiten für eine Klasse.

- God object

Mir gehts es hier nur mal um die ungefähre Strukturierung bzw. hierarchisierung von Projekten, vorallem im Einsatz von Einzelscripten.

Könntest du noch mal begründen, warum du auf Einzelskripte setzen möchtest?

 

[mermshaus]

Wenn ihr von Einzelscripts redet, meint ihr zB, dass die login.php aufgerufen wird, wenn man sich einloggen möchte, oder ein register.php, wenn man sich registrieren möchte und diese Datein werden nicht in eine umfassende Datei, wie main oder index.php eingebunden, sondern alleine aufgerufen?

Ja. Das sollten wir vielleicht so definieren.

Rufe ich nun auf der login.php oder register.php die HTML:rintBody(); Methode auf, die mir einfach nur </head><body> ausgeben soll, holt __autoload() die HTML Klasse und somit habe ich auf deren Methoden Zugriff? Somit werden auf jeder einzelnen Scriptseite nur die Dinge inkludiert, die man wirklich braucht - wodurch man ja wiederum Ladezeiten bzw. Serveranfragen einsparen kann!?

Serveranfragen: Nein, das passiert alles im Rahmen einer einzigen Anfrage von /<pfad>/<seite>.php. Includes und prinzipiell alles, was PHP tut, erzeugt keinen zusätzlichen HTTP-Request (wenn nicht gerade ein anderer Server angesprochen wird, aber dazu muss man wirklich wissentlich solchen Code schreiben).

Ladezeiten: Möglicherweise. Autoloading tut aber im Grunde genau das: Es bindet nur die Dateien ein, die benötigt werden. Das ist zumindest kein spezieller Vorteil von Einzelskripten. Ich behaupte, dass Einzelskripte keinen Geschwindigkeitsvorteil gegenüber einem FrontController-Layout haben.

autoload Funktionen sollten sparsam eingesetzt werden, da diese i.d.R. langsam sind. Ein klares Konzept ist flexibler und sicherer, als zuviel Automatismus. Ich halte es für sinnvoller, die Aktionen in einem zentralen Objekt zu speichern (das vom FC initiert wird) und die für die Anwendung notwendigen Eigenschaften dort abzufragen.

Die Aussage zum Autoloading ist theoretisch sicherlich nicht falsch, meiner Ansicht nach aber praktisch nicht relevant, weil es keinen anderen brauchbaren Mechanismus gibt. Ich halte es unter nahezu allen Umständen für einen Fehler, in einer OOP-Anwendung auf Autoloading zu verzichten.

Auch sollte eine Anwendung nicht so programmiert werden, dass möglichst wenige Dateien eingebunden werden müssen. Eine Anwendung sollte logisch nachvollziehbar programmiert/organisiert werden. Das ist sonst wirklich an der falschen Stelle gespart.

Ich empfehle, davon auszugehen, dass Autoloading/das Einbinden zusätzlicher Dateien per Include keinerlei Zeit beansprucht.

@struppi: Das ist jetzt nicht als absolute Gegenrede gemeint. Ich denke nur, dass das zitierte Stück schnell als „Autoloading ist böse“ gelesen werden könnte. Das steht da so nicht und das wäre auch total falsch. Autoloading ist heutzutage praktisch eine Standardvorgehensweise in der PHP-Programmierung.​

HTML:rintBody(): Ich mag solche Klassen nicht und ich mag auch statische Aufrufe nicht. Das schreit für mich förmlich danach, den entsprechenden Inhalt als Template/View-Script auszulagern. Dazu habe ich neulich ein Beispiel geschrieben. Das kann ich gleich mal verlinken, falls ich es irgendwo sinnvoll online abgelegt bekomme.

Einen FrontController muss bzw. kann man ja bei Einzelscripts auch einsetzen.

Dann sind die Einzelskripte aber nur noch „symbolische“ Links, die zum FrontController deuten. Wie gesagt, versuche vielleicht noch mal, zu begründen, warum du genau auf Einzelskripte setzen möchtest. Ich weiß da wirklich kein Argument.

Rufe ich in vBulletin auf forum.php ein Forum auf, soll ein Modul eingebunden werden, welches sich für den gewählten Forenbereich kümmert. Erstelle ich nun ein Thema, wird ein Request ausgeführt, also eine action - also FrontController kommen ja bei Einzelscripten genau so zum Einsatz, oder nich?

Siehe letzter Kommentar.

Wenn bei forum.php ein Thema/Thread oder eine Forenabteil ein modul ist, was ist dann forum.php selbst?

Wie ebenfalls bereits gesagt, zumindest crash und ich würden wohl vermuten, dass sich die Leute über sowas nicht wirklich Gedanken gemacht haben. Ich kann dir nicht sagen, warum diese Forensysteme so programmiert sind, wie sie programmiert sind. Aber ich bin mir sehr sicher, dass dir fast jeder neutrale Programmierer ohne Einblick in deren Organisationsabläufe sagen wird, dass der Ansatz hinsichtlich der Architektur nicht unbedingt empfehlenswert ist.

 

[struppi]

Bin grad am renovieren, kann mich daher leider nicht umfangreich hier beteiligen.

[...]
Grad beim schreiben der Antwort merke ich, wir reden vielleicht ein bisschen einander vorbei. Ich meine mit Autoload, die Funktion, die aufgerufen wird, wenn eine Funktion nicht gefunden wird. Das man dynamisch Module nachlädt ist logisch und sinnvoll. Mit Modulen meine ich Programmteile, die in externe Dateien ausgelagert sind.

 

[T!P-TOP]

Erstmal danke für die ausführliche Antwort, mermshaus!

Ich habe vor ein paar Wochen mein eigenes CMS fertig geschrieben. Habe da aber so gut wie gar nicht auf OOP gesetzt. 90% vom Code sind in den Admin Control Panel eingeflossen, allerdings ist da von oop eigentlich Null Spur - habe da einige Dinge mehrmals definiert und habe eher etwas schlampig programmiert. Daher möchte ich nun den gesamten ACP neu schreiben - wenn ich mir die Arbeit aber schon an tu, möchte ich gleich ein System entwickeln, was sich Blicken lassen kann, und habe da schon Probleme, mich nun halt zwischen Einzelscripten und meinem alten Stil zu entscheiden.
In der jetztige CMS Version binde ich verschiedene Scripte, oder nennen wir es Module (wie templates.php), in die index.php ein. Da man die einzelnene Datein nicht aufrufen darf, sofern man nicht eingeloggt ist, muss ich auf den einzelnen Modulen, wie eben templates.php, prüfen, ob eine Session registriert wurde und das Selbe auch noch auf der index.php - obwohl ich also alles über die index.php ableite, muss ich dennoch die Session zwei mal kontrollieren - daher dachte ich mir, ich versuch es dieses mal mit Einzelscripten, da ich dann lediglich einmal die Session prüfen muss.


Gut, zu der HTML Klasse kann ich jetzt nicht viel sagen, mir persönlich kam die praktisch vor - in einem PHP OOP Buch wurde sie vorgestellt.
Aber bzgl. OOP tue ich mir sehr schwer. In den Lernhilfen gibts immer so nette Beispiele mit Fahrzeugen, PKWs, LKWs usw. - da denkt man, man hat sofort den Durchblick, will man aber dann das Ganze an ein richtiges Projekt anwenden, scheitert das jedes mal.

Auf mein CMS bezogen:
Ich habe derzeit folgende Datein, welche ich in die index.php einbinde:

- pages.php
- templates.php
- images.php

pages.php ist dafür da, die angelegten Seiten auszugeben. Ansteuern tu ich die derzeit so:
blablablabla.at/index.php?module=pages

Will ich eine Seite editieren, sieht der Link so aus:
blablablabla.at/index.php?module=pages&action=edit&id=1

So editiere ich halt die Seite mit der id 1. Das ganze prüfe ich immer mit massenhaft if Bedingungen, wodurch halt n ziemlicher Spaghetticode am Ende rauskommt.


In templates.php gibt es 3 vordefinierte Templates, die man editieren kann, funktioniert ähnlich wir bei pages.php mit einer Menge if-else.

images.php ist dafür da, Bilder über den ACP in einen Ordner namens images hochzuladen.



Ok, und wie wende ich nun das Beispiel mit den Fahrzeugen an mein Mini CMS an?

So vielleicht?

class.cms.php
class.pages.php
class.templates.php
class.images.php

Die letzten 3 Klassen erben von der cms Klasse, in welcher eine MySQL Verbindung aufgebaut wird, außerdem werden dort Methoden definiert, die ich in den anderen 3 Klassen auch gebrauchen kann - so wird es jedenfalls in den fahrzeug-Beispielen beschrieben - die Überklasse ist sozusagen der Kern, in meinem Fall die cms Klasse, die anderen Klassen erben von diesem Kern.

Mermshaus, wie hast du den oop Stil erlernt?
Mit PHP Büchern habe ich es versucht, aber die Autoren rufen z.B. nicht statische Methoden mit dem Doppel Doppelpunkt auf - die machen teilweise mehr Blödsinn als ich

Sowas wie templates ist denen scheinbar auch noch nie untergekommen. Da wird das ganze Mark-up schön in den PHP Code reingedrückt.

Also bei mir haperts einfach am Aufbauplan - ich weiß nie wann ich eine Klasse definieren soll, wann nicht, wann sollen sie was geerbt bekommen usw. usf.

 

[crash]

OOP und die ganzen Design-Patterns und alles was dazu gehört lernt man am besten an einer Bibliothek, welche diese benutzt: also entweder Einzelbibliotheken oder ganze Frameworks. Im Zend Framework dürfte von Singleton, über Dependency Injection bis zu Adaptern alles drin sein.

 

[mermshaus]

Hier im Anhang (hoffe das klappt) ein relativ simples Beispiel eines OOP-FrontController-Layouts, wie es recht ähnlich etwa im Zend Framework eingesetzt wird. (Mein Beispiel ist dem ZF stark nachempfunden.)

Die aufzurufende Index-Datei liegt im public-Verzeichnis.

Weiterführend sind zu diesem Konzept beispielsweise ZF-Einführungen interessant:

- Tutorial: Getting Started with Zend Framework 1.11 – Rob Allen's DevNotes
- Zend Framework: Documentation: Zend Framework & MVC Introduction - Zend Framework Manual