Schnellstart mit Yii (2)

3. Controller (Controller)
Controller ist eine Instanz einer Unterklasse der CController-Klasse. Es wird von der Anwendung auf Anfrage des Benutzers erstellt. Wenn ein Controller ausgeführt wird, führt er die angeforderte Aktion aus (Controller-Klassenmethode), die normalerweise das erforderliche Modell einführt und die entsprechende Ansicht rendert. Eine Aktion ist eine Controller-Klassenmethode, deren Name mit Aktion beginnt (Aktion + Aktionsname mit Großbuchstaben).
Die Controller-Klassendatei wird in protected/controllers/ gespeichert.
Controller und Aktionen werden durch die ID identifiziert.
Die Controller-ID hat das Format „Übergeordnetes Verzeichnis/Unterverzeichnis/Controller-Name“, entsprechend der entsprechenden Controller-Klassendatei protected/controllers/übergeordnetes Verzeichnis/Unterverzeichnis/Controller-Name mit Großbuchstaben Controller.php ;
Die Die Aktions-ID ist der Name der Aktionsmethode ohne das Aktionspräfix.
1. Routing
Benutzer fordern bestimmte Controller und Aktionen in Form von Routing an. Routen werden durch eine Controller-ID und eine Aktions-ID verbunden, getrennt durch einen Schrägstrich.
Zum Beispiel repräsentiert die Route post/edit den PostController und seine Bearbeitung

Aktion. Standardmäßig fordert die URL http://hostname/index.php?r=post/edit diesen Controller und diese Aktion an.
Hinweis: Standardmäßig wird bei Routen die Groß-/Kleinschreibung beachtet. Sie können beim Routing die Groß-/Kleinschreibung nicht berücksichtigen, indem Sie CUrlManager::caseSensitive in der Anwendungskonfiguration auf „false“ setzen. Stellen Sie im Modus ohne Berücksichtigung der Groß- und Kleinschreibung sicher, dass Sie die Konvention befolgen, dass Verzeichnisnamen, die Controller-Klassendateien enthalten, Kleinbuchstaben sind und dass in Controller-Zuordnungen und Aktionszuordnungen verwendete Schlüssel Kleinbuchstaben sind.
Routing-Format: Controller-ID/Aktions-ID oder Modul-ID/Controller-ID/Aktions-ID (wenn es sich um ein verschachteltes Modul handelt, ist die Modul-ID die übergeordnete Modul-ID/Submodul-ID)
2. Controller-Instanziierung
Die Anwendung verwendet die folgenden Regeln, um die Controller-Klasse und den Speicherort der Klassendatei zu bestimmen:
1 Wenn CWebApplication::catchAllRequest angegeben ist, wird der Controller basierend auf diesem Attribut und der vom Benutzer angegebenen Controller-ID erstellt wird ignoriert. Dies wird normalerweise verwendet, um die Anwendung in den Wartungszustand zu versetzen und eine statische Eingabeaufforderungsseite anzuzeigen.
2. Wenn die ID in CWebApplication::controllerMap gefunden wird, wird die entsprechende Controller-Konfiguration zum Erstellen der Controller-Instanz verwendet.
3. Wenn die ID das Format „Pfad/zu/xyz“ hat, wird der Name der Controller-Klasse als XyzController beurteilt und die entsprechende Klassendatei wird geschützt/Controller/Pfad/zu/XyzController sein .php. Wenn die Klassendatei nicht vorhanden ist, wird eine 404CHttpException ausgelöst.
Bei Modulen prüft die Anwendung, ob diese ID einen Controller in einem Modul darstellt. Wenn ja, wird zuerst die Modulinstanz erstellt und dann werden die Controller-Instanzen innerhalb des Moduls erstellt.
3. Aktion
Aktion ist als eine Methode definiert, deren Name das Wort Aktion als Präfix enthält. Eine fortgeschrittenere Möglichkeit besteht darin, eine Aktionsklasse zu definieren und sie vom Controller instanziieren zu lassen, wenn eine Anfrage eingeht. Dadurch können Aktionen wiederverwendet werden, was die Wiederverwendbarkeit verbessert.
1. Definieren Sie eine Aktionsklasse wie folgt:
class UpdateAction erweitert CAction
{
publicfunction run()
{
// platzieren Sie die Aktionslogik hier
}
}
2. Aktionsklassen verwenden: Damit der Controller diese Aktion bemerkt, müssen wir die actions()-Methode der Controller-Klasse auf folgende Weise überschreiben:
Klasse PostController erweitert CController
{
publicfunction actions()
{
return array(
'edit'=>'application.controllers.post.UpdateAction',//Use "application Folder/controllers/ post/UpdateAction.php „Klasse in der Datei zur Bearbeitung der Bearbeitungsaktion
);
}
}
Wie oben gezeigt, haben wir den Pfadalias „application.controllers.post.UpdateAction“ verwendet, um Geben Sie die Aktionsklassendatei als „geschützt“ /controllers/post/UpdateAction.php“ an.
Durch das Schreiben klassenbasierter Aktionen können wir die Anwendung in einem Modulstil organisieren. Beispielsweise kann die folgende Verzeichnisstruktur zum Organisieren von Controller-bezogenem Code verwendet werden:
protected/
controllers/
PostController.php
UserController.php
post/
CreateAction.php
ReadAction .php
UpdateAction.php
user/
CreateAction.php
ListAction.php
ProfileAction.php
UpdateAction.php
4. Filter (Filter)
Ein Filter ist ein Codestück, das so konfiguriert werden kann, dass es vor oder nach einer Controller-Aktion ausgeführt wird.
Eine Aktion kann mehrere Filter haben. Wenn mehrere Filter vorhanden sind, werden diese in der Reihenfolge ausgeführt, in der sie in der Filterliste erscheinen. Filter können die Ausführung von Aktionen und anderen nachfolgenden Filtern verhindern.
Filter können als Methoden einer Controller-Klasse definiert werden. Namen von Filtermethoden müssen mit „filter“ beginnen. Beispielsweise definiert die vorhandene filterAccessControl-Methode einen Filter mit dem Namen accessControl. Die Filtermethode muss die folgende Struktur haben:
public function filterAccessControl($filterChain)
{
// Rufen Sie $filterChain->run() auf, um die Ausführung nachfolgender Filter und Aktionen fortzusetzen.
}
$filterChain (Filterkette) ist eine Instanz von CFilterChain, die eine Liste von Filtern darstellt, die mit der angeforderten Aktion verknüpft sind. Innerhalb der Filtermethode können wir $filterChain->run() aufrufen, um mit der Ausführung nachfolgender Filter und Aktionen fortzufahren.
Ein Filter kann wie eine Aktion auch ein Objekt sein, das eine Instanz von CFilter oder einer seiner Unterklassen ist. Der folgende Code definiert eine neue Filterklasse:
class PerformanceFilter erweitert CFilter
{
protected function preFilter($filterChain)
{
// Die Logik, die angewendet wird, bevor die Aktion ausgeführt wird
return true; // Wenn die Aktion nicht ausgeführt werden soll, geben Sie hier false zurück
}

protectedfunction postFilter($filterChain)
{
// Logik wird angewendet, nachdem die Aktion ausgeführt wurde
}
}

Um Filter auf eine Aktion anzuwenden, müssen wir die Methode CController::filters() überschreiben. Diese Methode sollte ein Array von Filterkonfigurationen zurückgeben. Zum Beispiel:
class PostController erweitert CController
{
......
publicfunction filter()
{
return array(
'postOnly + edit, create' , //Wenden Sie den postOnly-Filter an, um Aktionen zu bearbeiten und zu erstellen (dies ist ein methodenbasierter Filter)
array( //Ein Array wird zum Konfigurieren des Filters verwendet
'application.filters.PerformanceFilter - bearbeiten, erstellen',//Wenden Sie den application.filters.PerformanceFilter-Filter auf alle Aktionen außer Bearbeiten und Erstellen an (dies ist ein objektbasierter Filter)
'unit'=> ;'second' , //Initialisiere den Unit-Attributwert im Filterobjekt auf second
),
);
}
}
Der obige Code gibt zwei Filter an: postOnly und PerformanceFilter. Der postOnly-Filter ist methodenbasiert (die entsprechende Filtermethode wurde in CController definiert), während der performanceFilter-Filter objektbasiert ist. Der Pfadalias application.filters.PerformanceFilter gibt an, dass die Filterklassendatei protected/filters/PerformanceFilter ist. Wir konfigurieren den PerformanceFilter mithilfe eines Arrays, sodass er zum Initialisieren der Eigenschaftswerte des Filterobjekts verwendet werden kann. Hier wird der Einheitenattributwert von PerformanceFilter auf den zweiten Wert initialisiert.

Mithilfe der Plus- und Minuszeichen können wir festlegen, auf welche Aktionen der Filter angewendet werden soll und auf welche nicht. Im obigen Code sollte postOnly nur auf Bearbeitungs- und Erstellungsaktionen angewendet werden, und PerformanceFilter sollte auf andere Aktionen als Bearbeiten und Erstellen angewendet werden. Wenn in der Filterkonfiguration kein Plus- oder Minuszeichen verwendet wird, wird dieser Filter auf alle Aktionen angewendet.

5. Modell (Modell)
Ein Modell ist eine Instanz von CModel oder seiner Unterklasse. Modelle werden zum Speichern von Daten und der damit verbundenen Geschäftslogik verwendet.
Modelle sind separate Datenobjekte. Dabei kann es sich um eine Zeile in einer Datentabelle oder um ein vom Benutzer eingegebenes Formular handeln.
Jedes Feld des Datenobjekts entspricht einem Attribut im Modell. Jedes Attribut hat eine Bezeichnung und kann durch eine Reihe von Regeln überprüft werden.
Yii implementiert zwei Arten von Modellen: Formularmodell und Active Record. Beide erben von derselben Basisklasse CModel.
Formularmodelle sind Instanzen von CFormModel. Das Formularmodell wird verwendet, um Daten zu speichern, die aus der Eingabe des Benutzers stammen. Diese Daten werden häufig erfasst, verwendet und dann verworfen. Beispielsweise können wir auf einer Anmeldeseite das Formularmodell verwenden, um die vom Endbenutzer bereitgestellten Benutzernamen- und Passwortinformationen darzustellen.
Active Record (AR) ist ein Entwurfsmuster zur Abstraktion des Datenbankzugriffs in einem objektorientierten Stil. Jedes AR-Objekt ist eine Instanz von CActiveRecord oder einer seiner Unterklassen. Stellt eine Zeile in der Datentabelle dar. Die Felder in der Zeile entsprechen Eigenschaften im AR-Objekt.

6. Ansicht
Eine Ansicht ist ein PHP-Skript, das die Hauptelemente der Benutzerinteraktion enthält.
Die Ansicht hat einen Namen. Beim Rendern wird der Name zur Identifizierung der Ansichtsskriptdatei verwendet. . Der Name der Ansicht ist derselbe wie der Name des Ansichtsskripts. Beispiel: Der Name der Ansichtsbearbeitung stammt aus einer Skriptdatei namens edit.php. Rufen Sie zum Rendern CController::render() auf, indem Sie den Namen der Ansicht übergeben. Diese Methode sucht nach der entsprechenden Ansichtsdatei im Verzeichnis „protected/views/controller ID“.
Im View-Skript können wir über $this auf die Controller-Instanz zugreifen. Mit „$this->property name“ können wir jede Eigenschaft des Controllers in der Ansicht abrufen.
Wir können auch die folgende Push-Methode verwenden, um Daten an die Ansicht zu übergeben:
$this->render('edit', array(
'var1'=>$value1,
' var2 '=>$value2,
));
In der obigen Methode extrahiert die render()-Methode den zweiten Parameter des Arrays in eine Variable. Das Ergebnis ist, dass wir im View-Skript direkt auf die Variablen $var1 und $var2 zugreifen können.
1. Layout
Layout ist eine spezielle Ansichtsdatei, die zum Ändern von Ansichten verwendet wird. Es enthält normalerweise einen gemeinsamen Teil der Benutzeroberflächenansicht. Beispiel: Ein Layout kann Kopf- und Fußzeilenteile enthalten und dazwischen Inhalte einbetten.

......Kopfzeile hier......

......Fußzeile hier..... .

$content speichert das Rendering-Ergebnis der Inhaltsansicht.
Bei Verwendung von render() wird das Layout implizit angewendet. Das Ansichtsskript protected/views/layouts/main.php ist die Standard-Layoutdatei. Dies kann durch Ändern von CWebApplication::layout angepasst werden. Um eine Ansicht ohne Layout zu rendern, rufen Sie renderPartial() auf.
2. Kleine Objekte
Kleine Objekte sind Instanzen von CWidget oder seinen Unterklassen. Es handelt sich um eine Komponente, die hauptsächlich zur Darstellung von Daten verwendet wird. Widgets werden häufig in eine Ansicht eingebettet, um komplexe und unabhängige Benutzeroberflächen zu erstellen. Beispielsweise kann ein Kalender-Widget verwendet werden, um eine komplexe Kalenderoberfläche darzustellen. Gizmos machen Benutzeroberflächen wiederverwendbarer.
Wir können ein Widget gemäß dem folgenden Ansichtsskript verwenden:
beginWidget('Pfadalias der Widget-Klasse'[,'Array mit Attributinitialisierungswerten']); >
...Der Inhaltskörper, der vom Widget abgerufen werden kann...
endWidget();?>
oder
widget('Pfadalias der Widget-Klasse'[,'Array mit Attributinitialisierungswerten']);?>
Letzteres wird für Komponenten verwendet, die keinen Hauptinhalt benötigen.
Das Widget kann so konfiguriert werden, dass seine Leistung angepasst wird. Dies erfolgt durch den Aufruf von CBaseController::beginWidget oder CBaseController::widget, um den Wert seiner Initialisierungseigenschaft festzulegen.
Wir tun dies, indem wir ein Array mit den Initialisierungswerten dieser Eigenschaften übergeben. Die Schlüssel des Arrays sind die Namen der Eigenschaften und die Werte des Arrays sind die Werte, die den Widget-Eigenschaften entsprechen. Wie unten gezeigt:
$this->widget('CMaskedTextField',array(
'mask'=>'99/99/9999'
));
?>
CWidget erben und seine Methoden init() und run() überschreiben, um ein neues Widget zu definieren:
Klasse MyWidget erweitert CWidget
{
öffentliche Funktion init()
{
// Diese Methode wird von CController::beginWidget() aufgerufen
}
publicfunction run()
{
// Diese Methode wird von CController::endWidget()}
}
Ein Widget kann genau wie ein Controller eine eigene Ansicht haben.
Standardmäßig befinden sich die Ansichtsdateien von Widgets im Unterverzeichnis „views“ (protected/components/views), das das Verzeichnis der Widget-Klassendateien enthält. Diese Ansichten können durch den Aufruf von CWidget::render() gerendert werden, ähnlich wie bei einem Controller. Der einzige Unterschied besteht darin, dass die Ansicht des Widgets keine Unterstützung für Layoutdateien bietet. Darüber hinaus verweist $this in der Widget-Ansicht auf die Widget-Instanz und nicht auf die Controller-Instanz.

3. Systemansicht
Das Rendering der Systemansicht wird normalerweise verwendet, um Yii-Fehler und Protokollinformationen anzuzeigen.
Die Benennung von Systemansichten folgt einigen Regeln. Beispielsweise wird ein Name wie „errorXXX“ verwendet, um die Ansicht mit CHttpException mit der Fehlernummer XXX darzustellen. Wenn CHttpException beispielsweise einen 404-Fehler auslöst, wird error404 angezeigt.
Unter „framework/views“ stellt Yii eine Reihe von Standardsystemansichten bereit. Sie können angepasst werden, indem unter „protected/views/system“ Ansichtsdateien mit demselben Namen erstellt werden.

7. Komponenten
Yii-Anwendungen basieren auf Komponenten. Eine Komponente ist eine Instanz von CComponent oder einer seiner Unterklassen. Bei der Verwendung einer Komponente geht es vor allem darum, auf ihre Eigenschaften zuzugreifen und zu erfahren, wann sie ausgelöst oder verarbeitet werden soll. Die Basisklasse CComponent gibt an, wie Eigenschaften und Ereignisse definiert werden.
1. Komponenteneigenschaften
Die Eigenschaften einer Komponente sind wie die öffentlichen Mitgliedsvariablen eines Objekts. Es ist lesbar und beschreibbar.
Um eine Komponenteneigenschaft zu definieren, müssen wir nur eine öffentliche Mitgliedsvariable in der Komponentenklasse definieren.
Eine flexiblere Möglichkeit besteht darin, die Getter- und Setter-Methoden zu definieren, zum Beispiel:
public functiongetTextWidth() // Die textWidth-Eigenschaft abrufen
{
return$this->_textWidth;
( Groß- und Kleinschreibung wird beim Namen nicht beachtet). Wenn eine Eigenschaft gelesen wird, wird getTextWidth() aufgerufen, und ihr Rückgabewert wird zum Eigenschaftswert. Ebenso wird setTextWidth() aufgerufen, wenn eine Eigenschaft geschrieben wird. Wenn die Setter-Methode nicht definiert ist, ist die Eigenschaft schreibgeschützt und es wird eine Ausnahme ausgelöst, wenn darauf geschrieben wird. Ein Vorteil der Definition einer Eigenschaft mithilfe von Getter- und Setter-Methoden besteht darin, dass beim Lesen oder Schreiben der Eigenschaft zusätzliche Logik ausgeführt werden kann (z. B. Durchführen von Validierungen, Auslösen von Ereignissen).
Hinweis: Es gibt einen subtilen Unterschied zwischen durch Getter/Setter definierten Eigenschaften und Klassenmitgliedsvariablen: Bei Eigenschaftsnamen wird die Groß-/Kleinschreibung nicht beachtet, bei Klassenmitgliedsvariablen dagegen die Groß-/Kleinschreibung.
2. Komponentenereignisse
Komponentenereignisse sind spezielle Eigenschaften, die als Werte sogenannte Ereignishandler verwenden. Wenn Sie einem Ereignis eine Methode zuweisen, wird die Methode automatisch aufgerufen, wenn das Ereignis ausgelöst wird. Daher kann sich das Verhalten einer Komponente auf eine Weise ändern, die während der Komponentenentwicklung unvorhergesehen war.
Komponentenereignisse werden mit Namen definiert, die mit „on“ beginnen. Wie bei Eigenschaften, die durch Getter/Setter-Methoden definiert werden, wird bei Ereignisnamen die Groß-/Kleinschreibung nicht beachtet. Der folgende Code definiert ein onClicked-Ereignis:
public function onClicked($event)
{
$this->raiseEvent('onClicked', $event);
}
hier als event Der Parameter $event ist eine Instanz von CEvent oder einer seiner Unterklassen.
Wir können diesem Ereignis eine Methode wie folgt zuweisen:
$component->onClicked=$callback;
Hier zeigt $callback auf einen gültigen PHP-Callback. Es kann eine globale Funktion oder eine Methode in einer Klasse sein. Ist letzteres der Fall, muss es als Array bereitgestellt werden: array($object,'methodName').
Die Struktur des Event-Handlers ist wie folgt:
Name der Funktionsmethode ($event)
{
...
}
Das $event ist hier der Parameter, der das Ereignis beschreibt (aus dem raiseEvent()-Aufruf). Der Parameter $event ist eine Instanz von CEvent oder einer seiner Unterklassen. Es enthält zumindest Informationen darüber, wer das Ereignis ausgelöst hat.
Der Event-Handler kann auch eine anonyme Funktion sein, die von PHP 5.3 oder höher unterstützt wird. Zum Beispiel:
$component->onClicked=function($event) {
......
}
Wenn wir jetzt onClicked() aufrufen, wird das onClicked-Ereignis ausgelöst ( in onClicked()) wird der angehängte Event-Handler automatisch aufgerufen.
Ein Ereignis kann an mehrere Handles gebunden werden. Wenn ein Ereignis ausgelöst wird, werden diese Handler in der Reihenfolge ausgeführt, in der sie an das Ereignis gebunden waren. Wenn der Handler beschließt, die Ausführung nachfolgender Handler zu verhindern, setzt er $event->handled auf true.
3. Komponentenverhalten
Komponenten haben Unterstützung für Mixins hinzugefügt und können ein oder mehrere Verhalten binden. Ein Verhalten ist ein Objekt, dessen Methoden von den Komponenten, an die es gebunden ist, durch Sammelfunktionen geerbt werden können, und nicht durch spezialisierte Vererbung (d. h. gewöhnliche Klassenvererbung). Eine Komponente kann die Bindung mehrerer Verhaltensweisen durch „Mehrfachvererbung“ implementieren.
Verhaltensklassen müssen die IBehavior-Schnittstelle implementieren. Die meisten Verhaltensweisen können von CBeavior geerbt werden. Wenn ein Verhalten an ein Modell gebunden werden muss, kann es auch von CModelBehavior oder CActiveRecordBehavior erben, die Bindungsfunktionen speziell für das Modell implementieren.
Um ein Verhalten zu verwenden, muss es zunächst an eine Komponente gebunden werden, indem die Methode attachment() dieses Verhaltens aufgerufen wird. Dann können wir diese Verhaltensmethode über die Komponente aufrufen:
// $name identifiziert eindeutig das Verhalten in der Komponente
$component->attachBehavior($name,$behavior);
// test() ist eine Methode im Verhalten.
$component->test();
Auf gebundene Verhaltensweisen kann wie auf normale Eigenschaften in einer Komponente zugegriffen werden. Wenn beispielsweise ein Verhalten namens „tree“ an eine Komponente gebunden ist, können wir über den folgenden Code einen Verweis auf dieses Verhalten erhalten.
$behavior=$component->tree;
// entspricht dem folgenden Code:
// $behavior=$component->asa('tree');
Behavior can vorübergehend sein Wenn es verboten ist, ist seine Methode in der Komponente ungültig. Zum Beispiel:
$component->disableBehavior($name);
// Der folgende Code löst eine Ausnahme aus
$component->test();
$component->enableBehavior ($name);
// Jetzt können Sie es verwenden
$component->test();
Es ist möglich, zwei Verhaltensweisen mit demselben Namen an dieselbe Komponente zu binden. In diesem Fall hat die Aktion, die zuerst bindet, Vorrang.
Verhaltensweisen sind noch wirkungsvoller, wenn sie mit Ereignissen verwendet werden. Wenn ein Verhalten an eine Komponente gebunden ist, können einige Methoden im Verhalten an einige Ereignisse der Komponente gebunden werden. Auf diese Weise kann das Verhalten organisch beobachtet werden oder der reguläre Ausführungsfluss der Komponente verändert werden.
Auf die Eigenschaften eines Verhaltens kann auch über die Komponente zugegriffen werden, an die es gebunden ist. Zu diesen Eigenschaften gehören öffentliche Mitgliedsvariablen und Eigenschaften, die über Getter und/oder Setter festgelegt werden. Wenn ein Verhalten beispielsweise eine Eigenschaft xyz hat und dieses Verhalten an die Komponente $a gebunden ist, können wir mit dem Ausdruck $a->xyz auf die Eigenschaft dieses Verhaltens zugreifen.

8. Modul
Ein Modul ist eine unabhängige Softwareeinheit, die Modelle, Ansichten, Controller und andere unterstützende Komponenten enthält. In vielerlei Hinsicht sieht ein Modul wie eine Anwendung aus. Der Hauptunterschied besteht darin, dass ein Modul nicht einzeln bereitgestellt werden kann, sondern innerhalb einer Anwendung vorhanden sein muss. Benutzer können auf Controller in einem Modul genauso zugreifen, wie sie auf Controller in einer normalen Anwendung zugreifen würden.
Module sind in manchen Szenarien nützlich. Bei großen Anwendungen müssen wir es möglicherweise in mehrere Module aufteilen, und jedes Modul kann unabhängig gewartet und bereitgestellt werden. Einige gängige Funktionen wie die Benutzerverwaltung und Kommentarverwaltung können in Form von Modulen entwickelt werden, sodass sie in zukünftigen Projekten problemlos wiederverwendet werden können.
1. Erstellen Sie ein Modul
Module werden in einem Verzeichnis organisiert und der Verzeichnisname ist die eindeutige ID des Moduls. Die Struktur des Modulverzeichnisses ist dem Anwendungsbasisverzeichnis sehr ähnlich. Im Folgenden ist die typische Verzeichnisstruktur eines Fourm-Moduls aufgeführt:
Forum/ Modulordner
ForumModule.php-Modulklassendatei
Komponenten/ enthält wiederverwendbare Benutzerkomponenten
Ansichten/ enthält kleine Ansichtsdateien des Objekts
controllers/ enthält die Controller-Klassendatei
DefaultController.php Die Standard-Controller-Klassendatei
extensions/ enthält Erweiterungen von Drittanbietern
models/ enthält die Modellklassendatei
views/ enthält die Controller-Ansicht und das Layout Datei
layouts/ enthält die Layoutdatei
default/ enthält die Ansichtsdatei
index.php von DefaultController. Die Homepage-Ansichtsdatei

Modul muss eine von CWebModule geerbte Modulklasse haben. Der Name der Klasse wird durch den Ausdruck ucfirst($id).'Module' bestimmt, wobei $id die ID des Moduls (oder den Verzeichnisnamen des Moduls) darstellt. Modulklassen sind der zentrale Ort zum Speichern von Informationen, die zwischen Modulcode geteilt werden können. Beispielsweise können wir CWebModule::params verwenden, um Modulparameter zu speichern, und CWebModule::components, um Anwendungskomponenten auf Modulebene gemeinsam zu nutzen.
2. Module verwenden
Um Module zu verwenden, platzieren Sie zunächst das Modulverzeichnis im Modulordner des Anwendungsbasisverzeichnisses. Deklarieren Sie dann die Modul-ID im Modulattribut Ihrer App. Um beispielsweise das obige Forum-Modul zu verwenden, können wir die folgende Anwendungskonfiguration verwenden:
return array(
...
'modules'=>array('forum',... ) ,
...
);
Module können auch mit anfänglichen Attributwerten konfiguriert werden. Der Ansatz ist dem Konfigurieren von Anwendungskomponenten sehr ähnlich. Beispielsweise kann das Forum-Modul eine Eigenschaft namens postPerPage in seiner Modulklasse haben, die in der Anwendungskonfiguration wie folgt konfiguriert werden kann:
return array(
......
'modules'= > ;array(
'forum'=>array(
'postPerPage'=>20,
),
),
......
);
Auf Instanzen von Modulen kann über die Moduleigenschaft des aktuell aktiven Controllers zugegriffen werden. Innerhalb einer Modulinstanz können wir auf Informationen zugreifen, die auf Modulebene geteilt werden. Um beispielsweise auf die oben genannten postPerPage-Informationen zuzugreifen, können wir den folgenden Ausdruck verwenden:
$postPerPage=Yii::app()->controller->module->postPerPage;
// So wie $ this Wenn es sich bei der Referenz um eine Controller-Instanz handelt, können Sie die folgende Anweisung verwenden
//$postPerPage=$this->module->postPerPage;
Die Controller-Aktion im Modul kann über „Module ID“ weitergeleitet werden Zugriff auf „/Controller-ID/Aktions-ID“ oder „Modul-ID/Name des Unterverzeichnisses, in dem Controller-Klassendateien gespeichert sind/Controller-ID/Aktions-ID“. Angenommen, das obige Forummodul verfügt über einen Controller namens PostController, können wir über die Route forum/post/create auf die Erstellungsaktion in diesem Controller zugreifen. Die dieser Route entsprechende URL lautet http://www.example.com/index.php?r=forum/post/create.
3. Verschachtelte Module
Module können unendlich verschachtelt werden. Das bedeutet, dass ein Modul ein anderes Modul enthalten kann und dieses andere Modul andere Module enthalten kann. Ersteres nennen wir das übergeordnete Modul und letzteres das Untermodul. Untermodule müssen im Modulattribut ihres übergeordneten Moduls definiert werden, genau wie wir das Modul zuvor in der Anwendungskonfiguration definiert haben.
Um auf Controller-Aktionen in Submodulen zuzugreifen, sollten wir die Route-ID des übergeordneten Moduls/Submodul-ID/Controller-ID/Aktions-ID verwenden.

9. Pfadaliase
Pfadaliase werden in Yii häufig verwendet. Ein Pfadalias ist mit dem Pfad eines Verzeichnisses oder einer Datei verknüpft. Es wird in Punktsyntax angegeben, ähnlich dem weit verbreiteten Namespace-Format:
RootAlias.path.to.target
wobei RootAlias ​​​​ein Alias ​​eines vorhandenen Verzeichnisses ist, indem wir YiiBase::setPathOfAlias( ) aufrufen, wir kann neue Pfadaliase definieren. Der Einfachheit halber definiert Yii die folgenden Stammaliase:
system: stellt das Yii-Framework-Verzeichnis dar;
zii: stellt das Zii-Bibliotheksverzeichnis dar;
webroot: Gibt das Verzeichnis an, in dem sich die Eintragsskriptdatei befindet.
ext: Stellt das Verzeichnis dar, das alle Erweiterungen von Drittanbietern enthält.
Wenn die Anwendung außerdem Module verwendet, definiert (Yii) auch einen Root-Alias ​​für jede Modul-ID, der auf das Root-Verzeichnis des entsprechenden Moduls verweist.
Durch die Verwendung von YiiBase::getPathOfAlias() können Aliase in ihre entsprechenden Pfade übersetzt werden.
Durch die Verwendung von Aliasen können Klassendefinitionen einfach importiert werden. Wenn wir beispielsweise die Definition der CController-Klasse einschließen möchten, können wir den folgenden Code aufrufen
Yii::import('system.web.CController');
Die Importmethode unterscheidet sich von include und require und es ist effizienter. Eine importierte Klassendefinition wird erst dann tatsächlich einbezogen, wenn sie zum ersten Mal referenziert wird. Das mehrmalige Importieren desselben Namespace ist auch viel schneller als include_once und require_once.
Wir können auch die folgende Syntax verwenden, um das gesamte Verzeichnis zu importieren, sodass Klassendateien in diesem Verzeichnis bei Bedarf automatisch eingefügt werden.
Yii::import('system.web.*');
Außer dem Import verweisen Aliase auch auf Klassen an vielen anderen Stellen. Beispielsweise kann ein Pfadalias an Yii::createComponent() übergeben werden, um eine Instanz der entsprechenden Klasse zu erstellen. Auch wenn die Klassendatei noch nie zuvor enthalten war.
Verwechseln Sie Pfadaliase nicht mit Namespaces. Ein Namespace ist eine logische Kombination von Klassennamen, damit sie voneinander unterschieden werden können, auch wenn sie denselben Namen haben. Der Pfadalias wird verwendet, um auf eine Klassendatei oder ein Verzeichnis zu verweisen. Pfadaliase stehen nicht in Konflikt mit Namespaces.

Das Obige ist der Inhalt von Yii Quick Start (2). Weitere verwandte Inhalte finden Sie auf der chinesischen PHP-Website (www.php.cn)!