Referenz Implementierung: Bootstrap File

saphir2k · 13.03.2008, 22:21

Dies ist der 2. Teil unserer Todo Liste zum Thema "Bootstrap File" für das Zend Framework. Nähere Infos in diesem Thread:

Zielsetzung: Wie sieht das optimale Bootstrap File aus? Feste Benennung für Registry-Keys (Zend_Db, Zend_Translate, ...)

DennisBecker · 14.03.2008, 08:22

Bei den Registry-Keys bin ich bisher so verfahren, die Keys genauso zu nennen wir die Klasse selbst. Beim Zend_View_Helper_Translate wird sogar explizit nach "Zend_Translate" als Key in der Registry gesucht. Daher würde ich vorschlagen, dies so zu übernehmen.

PHP-Code:


			
Zend_Registry::get('Zend_Translate'); // wichtig für Zend_View_Helper_Translate
Zend_Registry::get('Zend_Db'); // Zend_Db Instanz an Models übergeben
Zend_Registry::get('Zend_Config'); // Config-Objekt brauch man ja öfters mal
Zend_Registry::get('Zend_Log'); // Schicke Logging-Instanz die eigentlich überall Verwendung finden sollte
Zend_Registry::get('Zend_Locale'); // brauche laufend die von mir gesetzte Locale und nicht die des Browsers, daher über die Registry verteilen ...

Wem fallen noch Klassen / Instanzen ein, die man immer wieder brauch und die über die Registry weitergegeben werden müssen?

[EDIT] Zend_Log nach Hinweis von t-mow hinzugefügt

t-mow · 14.03.2008, 09:03

Eventl. Zend_Log ?

DennisBecker · 14.03.2008, 09:08

Oh, stimmt, die Klasse hab ich total vergessen!

saphir2k · 14.03.2008, 21:11

Was ist mit Zend_Auth?

budcha · 14.03.2008, 23:35

Zitat:

Zitat von saphir2k

Was ist mit Zend_Auth?

Code:

Zend_Auth::getInstance()

Zitat:

Zitat von saphir2k

Zielsetzung: Wie sieht das optimale Bootstrap File aus? Feste Benennung für Registry-Keys (Zend_Db, Zend_Translate, ...)

Frage: Soll man jetzt Ideen posten oder eine Beispiel Bootstrap?

Z.b. verwende ich beim entwickeln "throw Exceptions = true" für den Dispatcher, aber auf dem produktions server selbst greift einfach nur der ErrorHandler.

PHP-Code:


			
# Zend FrontController initialisieren
$frontController = Zend_Controller_Front::getInstance();
$frontController->addModuleDirectory(PATH_TO_APPLICATION . $configGeneral->path->module);
$frontController->setParams($config->controller->params->toArray());
$frontController->returnResponse((bool) $config->controller->returnResponse);
$frontController->throwExceptions((bool) $config->controller->throwExceptions);

für "eigene Routen" benutzt ich ebenfalls eine config datei:

PHP-Code:


			
# Routes übergeben
$routes = new Zend_Config_Ini(PATH_TO_CONFIG . $configGeneral->routes->file, 'routes');
$router = $frontController->getRouter();
$router->addConfig($routes, 'routes');

PHP-Code:


			
# Dispatchen
try {
    $response = $frontController->dispatch(); # abhängig von "returnResponse"
    if ($response !== null) {
        if ($response->isException()) {
            $exception = $response->getException();
            throw $exception [0];
        }
        $response->outputBody();
    }
} catch (Exception $exception) {
    echo $exception;
}

Mr.AndersoN · 15.03.2008, 10:31

Wären wir schon beim nächsten:
Ich versuche soviel, wie möglich Config-Daten in einzelne Dateien auszulagern.
Routes sind bei mir zum Beispiel in einer extra routes.ini

saphir2k · 15.03.2008, 13:36

Zitat:

Zitat von budcha

Code:

Zend_Auth::getInstance()

Frage: Soll man jetzt Ideen posten oder eine Beispiel Bootstrap?

Am besten beides was deiner Meinung nach sinnvoll für unsere Basis App ist. Beispielcode mit Beschreibung ist natürlich immer am besten.
Du hast es ja schon optimal vorgemacht.

Leider trauen sich scheinbar viele nicht Ihren Code zu posten, was ich sehr schade finde, da man so sich auch Ideen von anderen holen kann.

saphir2k · 15.03.2008, 13:48

Zitat:

Zitat von Mr.AndersoN

Wären wir schon beim nächsten:
Ich versuche soviel, wie möglich Config-Daten in einzelne Dateien auszulagern.
Routes sind bei mir zum Beispiel in einer extra routes.ini

Extra Routen in einem eigenen File machen Sinn, stimmt. Das erhöht die Übersichtlichkeit ein wenig. Ich finde es zudem wichtig die Config nochmals aufzuteilen in einen Teil in dem die Pfade gesetzt werden sowie einem File das Anwendungspezifische Dinge setzt.

Der Grund ist ganz einfach. Wenn Mitarbeiter A via SVN oder CVS die Anwendung auscheckt auf seinem Windows Rechner muss er immer die Standardpfade anpassen damit die Anwendung läuft.
Nun kommt Mitarbeiter B mit seiner Linux Kiste und macht das gleiche wie A, die Pfade sind bei Ihm wieder anders.

Wenn Mitarbeiter A nun ausversehen die Konfig eincheckt in der die Pfade gesetzt werden, geht beim Update bei Mitarbeiter B nichts mehr.

Wenn man zwei getrennte Files für die Pfad Konfiguration und eine für den Rest kann man die "Pfad Konfigurations" Datei excludieren damit diese nicht mehr eingecheckt wird ausversehen. Die zweite Datei mit den restlichen Konfigurationen kann weiterhin von jedem Commited werden.

Ich hoffe jemand kann nachvollziehen was ich meine. ;-)

DennisBecker · 15.03.2008, 14:59

Du brauchst keine absoluten Pfade integrieren solange man PHP diese selbst erstellen kann, wie mit "dirname(__FILE)". Also der Ansatz irgendwas wegzulassen für SVN / CVS / GIT ist totaler Blödsinn. Man kann auch so entwickeln, dass es immer sowohl unter Windows als auch unter Linux läuft. Ein paar Vorraussetzungen muss man dafür aber allerdings schaffen, was man in dem Manual auch angeben kann & muss.

Routen würde ich absolut nicht in einem Basis-App berücksichtigen, da dies schon sher speziell ist und den Rahmen sprengt. Ich würde zum Beispiel Routen dynamisch über die DB handlen wollen und nicht fest in eine Datei schreiben.

Mr.AndersoN · 15.03.2008, 15:28

Warum Routen in die DB?
Dynamik brauch man dort doch nicht, wenn man ordentlich arbeitet.
Und wenn doch, dann kann man auch ein Frontend für die ini-Dateien schreiben - kommt auf das selbe hinaus.

budcha · 15.03.2008, 18:42

Zitat:

Zitat von saphir2k

Leider trauen sich scheinbar viele nicht Ihren Code zu posten, was ich sehr schade finde, da man so sich auch Ideen von anderen holen kann.

mal nen bischen arbeit gemacht, ist noch lange nicht perfekt ...

beispiel bootstrap
http://www.paste2.org/p/16040

das ganze :
http://budcha.de/zf/trunk.zip

DennisBecker · 15.03.2008, 21:07

Zitat:

Zitat von Mr.AndersoN

Warum Routen in die DB?
Dynamik brauch man dort doch nicht, wenn man ordentlich arbeitet.
Und wenn doch, dann kann man auch ein Frontend für die ini-Dateien schreiben - kommt auf das selbe hinaus.

Ok, nehmen wir an, du hast Modul "A", welches über diverse Routen aber andere Inhalte liefern soll. Da will man keinen Website-Admin dazu auffordern, eine INI-Datei zu ändern, zumal er wahrscheinlich (richtet sich nach der Zielgruppe) keine Ahnung vom ZF haben wird. Darum will ich gar keine Implementierung in solch einer Basis-Applikation sehen, da dies viel zu spezifisch ist.

saphir2k · 15.03.2008, 21:09

Zitat:

Zitat von Radhad

Du brauchst keine absoluten Pfade integrieren solange man PHP diese selbst erstellen kann, wie mit "dirname(__FILE)". Also der Ansatz irgendwas wegzulassen für SVN / CVS / GIT ist totaler Blödsinn.

Da muss ich dir energisch wiedersprechen. In der Praxis wirst du immer einige Pfade haben die du nicht in PHP generieren kannst. Als Beispiel Temp Ordner, Caching Ordner, Pfad zum Image Server bzw. Media Server usw. um nur ein paar zu nennen. Es geht mir nicht nur um unterschiedliche OS, es geht mir auch um unterschiedliche Rechner mit unterschiedlichen Installationen. Ich spreche aus Erfahrung.

Zitat:

Zitat von Radhad

Routen würde ich absolut nicht in einem Basis-App berücksichtigen, da dies schon sher speziell ist und den Rahmen sprengt. Ich würde zum Beispiel Routen dynamisch über die DB handlen wollen und nicht fest in eine Datei schreiben.

Sorry da bin ich auch anderer Meinung. Wir sollten zumindest den richtigen Platz dafür finden, auch wenn wir (so wie du richtig schreibst) in der Basis App evtl. keine Verwendung dafür haben. Schön wäre es doch dem User gleich den richtigen Platz anzubieten.
[EDIT:]Dank isXmlHttpRequest() braucht man ja auch nun keine eigenen Route mehr.

Aber das ist wie gesagt alles nur meine Meinung. Ich lasse mich immer gerne Inspirieren von anderen Gedanken.

saphir2k · 15.03.2008, 21:16

Zitat:

Zitat von Radhad

Ok, nehmen wir an, du hast Modul "A", welches über diverse Routen aber andere Inhalte liefern soll. Da will man keinen Website-Admin dazu auffordern, eine INI-Datei zu ändern, zumal er wahrscheinlich (richtet sich nach der Zielgruppe) keine Ahnung vom ZF haben wird. Darum will ich gar keine Implementierung in solch einer Basis-Applikation sehen, da dies viel zu spezifisch ist.

Oha, das ist aber ein sehr exclusiver Fall. ;-) Du hast also ein Admin Interface das auch die Route ändern kann? Da würd ich mir lieber den Admin zur Brust nehmen und ihm das 2 Minuten erklären. Routen in die DB wäre mir alleine aus Performance gründen zu aufwändig.

Was meint der Rest der Horde?

mahok · 16.03.2008, 16:34

@Radhad: Könntest du dein Beispiel etwas konkreter machen, ich sehe immer noch nicht wieso ich dafür die Routes in eine Db auslagern soll?

Ich handhabe es so, dass mein bootstrap-Datei eine Methode getConfig() zur Verfügung stellt, welche eine config-Datei einliest, in die Registry speichert (Dateiname ohne Endung) und das Zend_Config-Objekt zurückgibt.

Damit kann ich in einem Modul oder Plugin einfach Konfigdateien laden und diese auf Wunsch auch gleich in der Registry speichern, wenn also die "Standardrouten" nicht ausreichen, erstelle ich einfach eine modulspezifische Config und lade diese vom Modul aus...

PHP-Code:


			
    /**
     * load config file and store in Zend_Registry
     *
     *    @param    string      $path      path to config-file
     *    @param    string      $section   section (i.e. production, staging)
     *    @param    bool        $register  store config-data in Zend_Registry?
     *    @return   Zend_Config            configuration-data as Zend_Config
     */
    public static function getConfig($path, $section = 'production', $register = true)
    {
        $config = null;        // dummy-var for config-data

        if(is_readable($path))
        {
            // generate ConfigId from filename
            $temp = explode(DIRECTORY_SEPARATOR, $path);
            $temp = explode('.', $temp[count($temp) - 1]);
            $configId = $temp[0];
            $fileType = $temp[1];

            if($fileType == 'xml')
            {
                $config = new Zend_Config_Xml($path, $section);
            } else if($fileType == 'ini') {
                $config = new Zend_Config_Ini($path, $section);
            } else throw new Zend_Exception('Unknown filetype (' . $fileType . ') for ' . $configId);

            if($register)
            {
                Zend_Registry::set($configId, $config);
            }
        } else throw new Zend_Exception('Configfile (' . $path . ') is not readable');

        return $config;
    }

Wenn ich einem Nutzer nicht zutraue die Konfigurationsdateien selbst zu bearbeiten, kann man ja (wie Mr. AndersoN schon schrieb) ein Frontend zum Bearbeiten der Dateien erstellen, auf diese Weise kann man über eine Administrationsoberfläche die Einstellungen machen oder zwischen verschiedenen Konfigurationen (z.B. Front-/Backends für Cache) wählen lassen und nötigenfalls Feineinstellungen betreiben.

DennisBecker · 16.03.2008, 17:08

Nehmen wir als Beispiel eine Seite, welche diversen Teams unterschlupf gewährt. Jedes Team soll per URL auf ihre Startseite kommen.

Wir haben also auf der einen Seite die eigentliche Seite:
www.example.com

Und auf der anderen Seite mehrere Teams:
www.example.com/apfel
www.example.com/birne
www.example.com/banane
www.example.com/melone

Alle diese Seiten werden auf ein und dasselbe Modul geroutet, so dass der Kern für alle Teams gleich ist. Automatisiert können sich weitere Teams anmelden. In dem Falle ist eine Datenbank sehr viel praktischer als eine INI-Datei. Und das war jetzt nur ein ziemlich einfaches Beispiel. Stellt euch das mal bei einem Verlag vor.

Oder nehmen wir an, es gibt ein Modul "Kalender". Dieser soll überall eingebunden werden könnnen. Man hat seine Teamseite "www.example.com/apfel" und will darinne einen Kalender haben namens "Meetings". Nun will man diesen Kalender über folgende URL erreichen: www.example.com/apfel/meetings - INI Dateien wären hierfür auch eine schlechte Wahl. Es wäre nun auch möglich, einen Kalender für "Urlaub" zu erstellen: www.example.com/apfel/urlaub

Ich hoffe nun wird das ganze etwas klarer. Mit Routing kann man geschickt Module "visuell" unter anderen Modulen / Seiten einordnen und der Enduser merkt das nicht einmal.

saphir2k · 16.03.2008, 20:41

Ok dir gehts um den Automatismus dahinter, verstehe.

Können wir uns darauf verständigen das wir im ersten Schritt die Routen ganz "Standard" lassen? Wärst du damit einverstanden?

Ich denke ALLE Feinheiten werden wir nicht abdecken können, aber wir können ja mehrere Versionen erstellen. Ich fände es nur wichtig das wir schnell zu einem Punkt kommen, mit dem jeder Leben kann.

Mein Vorschlag mit den getrennten Konfig Files können wir gerne auch zurückstellen. Kein Thema.

Spea · 16.03.2008, 20:59

Zitat:

Zitat von budcha

mal nen bischen arbeit gemacht, ist noch lange nicht perfekt ...

beispiel bootstrap
http://www.paste2.org/p/16040

das ganze :
http://budcha.de/zf/trunk.zip

Gefällt mir so schon ganz gut, wobei ich persönlich die ganzen Konfigurationsparameter in die config.php packen würde, und nur den Dispatch in die index.php. Ist aber wohl Geschmackssache.

Gruß

Spea

budcha · 16.03.2008, 22:14

Zitat:

Zitat von Spea

Gefällt mir so schon ganz gut, wobei ich persönlich die ganzen Konfigurationsparameter in die config.php packen würde, und nur den Dispatch in die index.php. Ist aber wohl Geschmackssache.

ist wirklich geschmackssache

dadurch splittest du praktisch noch mehr.

hab vorn paar tagen mit einer anderen art das zu splitten (aufzuröumen) rumgespielt, ner "main" klasse die von der index required wird und wo man dann dezidiert einzelne punkte aufrufen kann. war ganz lustig, aber auch nicht das ware (wobei da der "wenn was schief läuft" ausgebauter war, bei dem beispiel echo ich nur die exceptions)