[Du-weisst-schon-wer]

Hallo,
ich stecke momentan etwas im Planungsfimmel und bin auf der Suche nach Ideen wir man eine Webseite optimal konstruiert.

Ich hätte mal gerne von euch gewusst wie eure Seiten so arbeiten sprich:

Wie und wodurch werden Inhalte dargestellt?
Was für Systeme setzt ihr ein (z.B. Smarty)
Benutzt ihr Frameworks?
Wie sieht euer OOP Design aus?*
Woher kommen eure Inhalte (Datenbank, Formatierte Dateien e.g. XML Formate) und wie weit sind sie dynamisch gehalten?
Verschiedene Sprachen? Wie wird das bei euch gehändelt?


Gruß DWSW

[Corvin]

Hi.

Wie und wodurch werden Inhalte dargestellt?

Wie meinst du das?

Was für Systeme setzt ihr ein (z.B. Smarty)
Benutzt ihr Frameworks?

Ja, ich arbeite mit einem eigenem Framework. Das beinhaltet natürlich auch ein eigenes Templatessystem.

Wie sieht euer OOP Design aus?*

Mein PHP-Code errinnert wahrscheinlich an Java. So ist bei mir zum Beispiel die index.php i.d.R. aufgebaut:

PHP-Code:

<?php
include('classes/error.class.php');
include('classes/db.class.php');
include('classes/page.class.php');
include('classes/template.class.php');

class Index extends Page
{

    public function __construct() {
        $this->startUp('index.tpl');
        $this->main();
        $this->macheDies();
        $this->macheDas();
        $this->output();
        return true;
    }
    
    protected function main() {
        $this->tpl->assign('hometitle', $this->cfg['hometitle']);
        $this->tpl->assign('title', $this->lang['start']);
        return true;
    }

    protected function macheDies() {
        //...
    }

    protected function macheDas() {
        //...
    }

}

new Index;
?>

Woher kommen eure Inhalte (Datenbank, Formatierte Dateien e.g. XML Formate)?

I.d.R. aus der Datenbank.

[CIX88]

Wie wird das bei euch gehändelt?

Beim Kaffeetrinken mit Zettel und Stift ...

Bevor man hier mit Frameworks, OOP Design und/oder Datenbanken umsich schlägt, erstmal überlegen was man will.
Ein wichtiger Punkt, der sehr oft übersehen wird.

[Du-weisst-schon-wer]

Zitat von CIX88

Beim Kaffeetrinken mit Zettel und Stift ...

Bevor man hier mit Frameworks, OOP Design und/oder Datenbanken umsich schlägt, erstmal überlegen was man will
Ein wichtiger Punkt, der sehr oft übersehen wird.

Sicher.
Ich weiss das man immer den Einzelfall betrachten muss.
Aber ich wollte einfach nur mal ein paar Baupläne von Webseiten mir angucken. Für eventuelle neue Ideen etc.

[pago]

Wenn der Corvin schon so fröhlich seine Index-Seiten postet...
Die Index-Seite meines neuen CMS sieht aktuell so aus:

PHP-Code:

<?php
error_reporting(E_ALL); // @todo Remove once we're in production

// define root of Dino2 (this time we'll figure it out by ourself)
define('DS_ROOT', dirname(__FILE__).'/');

// misc stuff, better done first, needs to be here
require_once(DS_ROOT.'config.inc.php');
require_once(DS_ROOT.'dstk/ClassLoader.class.php');
require_once(DS_ROOT.'util.php');

// import known and required packages
ClassLoader::getInstance()->importExternalPackage('creole');
ClassLoader::getInstance()->importExternalPackage('jargon');
import('dstk');
import('smarty');

// build up the website
$index = new IndexComponent();
$index->init(null);
$content = $index->render();
echo $content;
?>

Daran lassen sich folgende Erkenntnisse gewinnen:
1. Ich verwende Smarty als Template-Engine
2. Ich verwende Creole als Datenbank-Klasse
3. Ich verwende ein eigenes "Framework"

Meine bisherige Idee ist relativ simpel: Webseiten bestehen aus diversen Elementen, die im Normalfall nichts miteinander zu tun haben.
Es gibt ein Menü, es gibt einen Inhaltsbereich, vielleicht ein Login-Fenster, etc., jede dieser Komponenten ist ein eigenständiges Objekt. Geladen werden die Komponenten bei mir in einem Template.
In der init-Methode verarbeitet die Komponente dann eventuelle Parameter und lädt das Model (z.B. aus einer XML-Datei oder aus der Datenbank). In der render-Methode wird dann das View geladen (Smarty-Template) und als String zurückgegeben.
So setzt sich die Seite aus ihren einzelnen Komponenten zusammen.

Wie ich Mehrsprachigkeit realisieren werde, weiß ich noch nicht. Mein aktueller Entwurf liest ein "ResourceBundle" und speist alle darin enthaltenen Informationen in's Template. Das macht die Basis-Klasse "Component" voll automatisch. Das ResourceBundle (z.B. "Bundle_de.properties") liegt dabei im gleichen Verzeichnis, in dem auch die Komponente definiert ist. Ob das so bleibt weiß ich allerdings nicht.

Wobei ich vielleicht hinzufügen sollte, dass dieses CMS selbst nur ein Framework seien wird (wie die erste Version auch).

[$traight-$hoota]

Ich hab da mal ne frage bezüglich klassen-einbindung:
corvin bindet seine klassen direkt mittels include ein (besser wäre aber "require_once", oder?) und pago verwendet nen classloader mit packages.
ich hab mir auch mal überlegungen dazu gemacht, wie man seine klassen am besten organisiert und dabei ist folgendes rausgekommen:
alle klassen liegen liegen in einem verzeichnis bzw dessen unterordnern. diese werden dann alle eingelesen und in ein array gespeichert (als "ClassName" => "package/subpackage/ClassName.class.php"), das natürlich gecached wird.
mittels der __autoload() funktion werden dann bei bedarf die benötigten dateien eingebunden.
Das erspart einem natürlich die ganze arbeit, jede klasse bzw jedes package einzeln einzubinden, aber vor allem bei größeren klassenbibliotheken dauert das ganze halt länger als andere methoden.

[pago]

Mein "System" ist nicht wirklich gut... ich muss mir da noch'n bisschen was überlegen, wie ich das sinnvoller machen kann.
Momentan schaue ich in allen Verzeichnissen, die ge"import"ed wurden, ob dort eine Datei existiert, die zum Muster "$classname.class.php" passt. "importExternal" macht prinzipiell das gleiche, nur ohne ".class", weil creole das nicht im Dateinamen hat (smarty, z.B., aber schon).

Davon abgesehen sieht meine Verzeichnis-Struktur ziemlich genauso aus, wie deine.

[Lars]

PHP-Code:

<?php

$root = '.';
define('FRAMY_DIR', $root.'/Framy');

require_once FRAMY_DIR.'/Framy.php';

$cfg = new Config($root.'/config.ini');
$cfg->addSource('mysql:Dbname=framy;dbtable=tbl__config');

$framy = new Framy($cfg);
$framy->setAttributes(array(
  Framy::URL_TYPE => Framy::URL_REWRITE)
);

$framy->loadModule(new Blog($cfg));

$output = $framy->makeOutput(Framy::OP_HTML);
$output->flush();

?>

[beny_mcde]

Zitat von $traight-$hoota

alle klassen liegen liegen in einem verzeichnis bzw dessen unterordnern. diese werden dann alle eingelesen und in ein array gespeichert (als "ClassName" => "package/subpackage/ClassName.class.php"), das natürlich gecached wird.
mittels der __autoload() funktion werden dann bei bedarf die benötigten dateien eingebunden.

diesen ansatz habe ich zu anfang auch verfolgt, bin aber wieder vom __autoload
weggegangen, da das mehr aufwand als nutzen ist.

mein ansatz sieht in etwa so aus. Es gibt wie auch bei pago einen ClassLoader
(Java lässt grüßen). dieser hat methoden wie requireClass und requireScript, sowie auch die methode newInstance.
möglichst alle klassen sollten durch die methode newInstance erstellt werden, der ClassLoader überprüft dann ob die angeforderte klasse schon eingebunden wurde, wenn nicht wird sie über die methode requireClass eingebunden.

die klassen werden nicht über ihren eigentlichen pfad, sondern über einen Klassenpfad angesprochen.
eine core klasse z.B.
src/classes/util/Test.class.php
wird über den Klassenpfad CORE.util.Test angesprochen. Der Pfad wird dann vom ClassLoader in der methode classpathToFile aufgelößt.
Includes werden im Ordner src/includes/dateiname.inc.php aufbewahrt und können über den Klassenpfad INC.dateiname angesprochen werden.
hier ist es eigentlich nicht korrekt von einem Klassenpfad zu sprechen aber das habe aus gründen der einfachheit vernachlässigt.

OptionaleKlassen die nicht zum Core gehören werden in Packages aufbwahrt, welche durch ein unterverzeichnis im ordner packages aufbewahrt werden.
Der Klassenpfad PAK.test.Class1 verweißt dann also auf packages/test/Class1.class.php

Des weiteren kann man in einer Konfigurationsdatei für jeden Klassenpfad statische Konfigurations attribute definieren, welche dann in der newInstance methode auf die instanzierte klasse übertragen werden.

 class TestClass extends Base{
  protected $attrib1;
  protected $attrib2;
  function __construct($conf){
   parent::__construct($conf);
  }
 }

so sieht eine einfache klasse aus.
nehmen wir mal an die datei befindet sich in dem package test.
um der klasse eine statische konfiguration hinzuzufügen würde man also in der konfig datei folgendes hinzufügen

 PAK.test.Class {
 attrib1 = test
 attrib2 = nocheintest
 }

der code um eine neue instanz zu erstellen währe wie folgt

 $t = ClassLoader::newInstance('PAK.test.TestClass');

um die statische konfiguration zu überschreiben kann man den code auch so um schreiben

 $conf = array(
                    'attrib1'=>'überschriebener test'
                   );
 $t = ClassLoader::newInstance('PAK.test.TestClass',$conf);

Die klassen über eine methode zu instanzieren hat gegenüber dem direkten erzeugen mit new einige vorteile.
so ist es in meinem framework auch möglich klassen zu überschreiben.

 OVERRIDES {
  PAK.test.TestClass = PAK.test1.TestClassHack
 }

würde bewirken, daß jedesmal wenn die Klasse PAK.test.TestClass mit der newInstance methode angefordert wird die Klasse PAP.test1.TestClassHack instanziert und zurückgegeben wird.

Im moment bin ich dabei noch einen leichtgewichtigen aspektorientierten ansatz zu erarbeiten, mit dem es letzendlich möglich sein wird aspekte einer klasse hinzuzufügen ohne den php code zu ändern.

[$traight-$hoota]

@beny_mcde
das hört sich ganz praktisch an.
aber was für einen vorteil haben die konfigurationsdateien?
oder ist das halt einfach ne framework erweiterung, die man aber an sich nicht umbedingt braucht?

PAK.test.Class

müsste das nicht

PAK.test.TestClass

heißen?

[beny_mcde]

Zitat von $traight-$hoota

aber was für einen vorteil haben die konfigurationsdateien?

die konfigurationsdatei hat den vorteil, das sie ein wesentlich einfacheres format hat, beim ersten aufruf wird die datei in einen php array umgewandelt, der etwa so aussieht.

PHP-Code:

$GLOBALS['CONF']=array(
 'PAK'=>array(
                 'test'=>array(
                                    'TestClass'=>array(
                                                              'attrib1'=>'bla',
                                                              'attrib2'=>'bla',
                                                             )
                                  )
                )
); 


(VB zerschießt meine formatierung....)

wie man unschwer erkennen kann ist diese schreibweise sehr schwer zu lesen
und es schleichen sich schnell fehler in form von vergessenen klammern/anführungszeichen und kommas ein. das hat zur folge das das gesamte script mit einem parser error abgebrochen wird, nur wegen der konfiguration.
beim umwandeln der konfig datei werden fehlerhafte einträge einfach nicht beachtet bzw korrigiert.

da ich in manchen projekten auch die seitendefinition in der konfiguration erledige, hatte ich in naher zukunft geplant eine graphische administration für die konfigurationsdateien zu bauen.
das format lässt sich wesentlich besser parsen und wieder schreiben als eine phpdatei mit verschachtelten arrays.

SECTIONS{
 home {
  mainTemplate = template.html
  contentTemplate = home/content.html
 }
 home.news {
  mainTemplate = template.html
  contentClass = PAK.news.content.NewsContent
 }
}

die seiten können dann über "index.php?page=home", "index.php?page=home.news" mit mod_rewrite über
"/home/index.html", "/home/news/index.html" abgerufen werden,

Zitat von $traight-$hoota

müsste das nicht

heißen?

ups... da hab ich mich wohl verschrieben.... also es müsste wirklich PAK.test.TestClass heißen...

[Jojo]

Meine bisher erste PHP5-Index-Datei sieht so aus.

PHP-Code:

<?php
error_reporting(E_ALL);

 // This magic function loads all required class files on demand
function __autoload($classname) {
    global $config;
      $classname = str_replace('_', '/', $classname);
    $require = require_once($config['site']['path'].'/src/' . $classname . '.php');
    if (!$require) echo 'File '.dirname($_SERVER['SCRIPT_FILENAME']).'/src/' . $classname . '.php not found!';
}

// loading main configuration file
$main_config = require(dirname($_SERVER['SCRIPT_FILENAME'])."/site/config.inc.php");
if (!$main_config) die('Fatal Error: Main configuration file not found!');
session_start();
 
// getting an old instance of main class or creating a new one
try {
    $Stufensite = (!empty($_SESSION['Stufensite']) && $_SESSION['Stufensite'] instanceof core_Stufensite) ? $_SESSION['Stufensite'] : new core_Stufensite();
    $Stufensite->init();
    $_SESSION['Stufensite'] = $Stufensite;
    }
    catch (Exception $e) {
        echo "Error: ".$e->getMessage();
    }
}

?>

Naja, richtig zufrieden bin ich nicht. k.a. warum.
Den File-Loader hab ich mir von Guradia abgeguckt. Fand ich ganz sinnvoll und lustig.

Meine Struktur sieht so aus:
im Unterordner src/ sind alle Classfiles abgelegt. Dabei arbeite ich pluginbasiert, was ich später noch automatisieren will. auf jeden Fall gibt es im Grunde 2 Arten von Ordnern in src/: Plugin-Ordner, in denen Klassen zu einem Plugin, wie einer Shoutbox, einem News-System, etc. abgelegt sind, sowie einem "core"-Ordner, in dem Hauptklassen der Seite sowie nützliche Utitlies, wie einer Entpacker-Klasse, einer Form-Klasse (die zugegeben nur eins is: überladen), einer Template-Klasse, die auch PHP-Code innerhalb eines Templates parsen lässt, oder einer MySQL-Klasse, die sich beim deserialisieren wieder neu verbindet.

Die Plugins sind nach einer gewissen Logik aufgebaut.
Wenn man also den Code eines Newssystem haben möchte, erstellt man z.B. eine Instanz von NewsSys_NewsSys(); und lässt sich den Code per get_Code() zurückgeben.

In der config-Datei werden globale Config-Daten bereitgestellt, mit denen auch die PHP-Codes innerhalb der Templates arbeiten können.

Bislang ist das recht.......ähh..........ineffizient. Naja, vielleicht konnte ich den ein oder anderen inspirieren, oder kann selbst noch was lernen, was super wäre, denn wirklich zufrieden bin ich mit dem Ganzen nicht wirklich.

[Creativ]

Hi,
also mein grundaufbau ist zur zeit dass ich eine global.php habe, wo ich dann die klassen aufrufe und objekte erstelle usw. und wichtige variablen festlege. (MysqlDaten sind dann aber in der config.php)

Und dann habe ich die index.php, in der ich die global.php einbinden und dann die verschiedenen seiten einbinde (mache das mit index.php?page=...).
Als template-system verwende ich smarty und als mysql-klasse meine eigene.

Habe dann noch paar Fragen:
Was ist ein Framework und warum benutzt ihr das? Was ist der Vorteil davon?
Oder ist ein Framework einfach nur ein bisschen wie meine global.php.
Also wo dann template-klasse und mysql-klasse und alles zusammen ist und dass man dann nur noch die ausgabe machen muss und der rest ist das gleiche?

[freezer]

Bei Wikipedia gibt es eine gute und ausführliche Definition zu "frameworks":
http://de.wikipedia.org/wiki/Framework

[Lars]

Zitat von WarrenFaith aus einem internen Forum.

Zitat von WarrenFaith

Ein Framework wäre nach meinem Verständnis eine sinnvolle Klassenstruktur, die einem für allgemeine Dinge schon alles bereitstellt (Templateklasse, DB-Klassen, Errorhandling, Sicherheitsklassen etc)

[lycoos]

Was bringt denn dann eigentlich diese Framework genau??? Was erleichtert das einem???