Bitte geben Sie die Quelle für den Nachdruck an: Yii Quick Start (1)
Ⅰ. Grundkonzepte
1. Inhalt der Eintragsdatei: Das allgemeine Format ist wie folgt:
$yii=dirname(__FILE__).' /.. /../framework/yii.php';//Yii-Framework-Speicherort
$config=dirname(__FILE__).'/protected/config/main.php';//Der Hauptspeicherort der Konfigurationsdatei des aktuelle Anwendung
//Entfernen Sie beim Bereitstellen der formalen Umgebung die folgende Zeile
// definiert('YII_DEBUG') oder define('YII_DEBUG',true);//Ob im Debug-Modus ausgeführt werden soll
require_once($yii);//Enthält das Yii-Framework
Yii::createWebApplication($config)->run();//Erstellen Sie eine Anwendungsinstanz basierend auf der Hauptkonfigurationsdatei und führen Sie sie aus . Sie können über Yii::app() von überall in der aktuellen Anwendung auf diese Instanz zugreifen.
2. Hauptkonfigurationsdatei
Speicherort: Ihre Anwendung/protected/config/main.php
Dateiinhalt: Das allgemeine Format ist wie folgt:
return array(
'basePath'=>dirname(__FILE__).DIRECTORY_SEPARATOR.'..', //Der absolute physische Pfad des aktuellen Anwendungsstammverzeichnisses
'name'=>'Yii Blog Demo', //Der Name der aktuellen Anwendung
// Laden Sie die Protokoll-(Aufzeichnungs-)Anwendungskomponente vor, was bedeutet, dass die Anwendungskomponenten unabhängig davon erstellt werden, ob auf sie zugegriffen wird oder nicht Die Anwendung wird unten als „Komponenten“ konfiguriert. Im Array der Schlüsselwörter
'preload'=>array('log') //log ist die Komponenten-ID
// Automatisch geladenes Modell festgelegt und Komponentenklasse
' import'=>array(
'application.models.*', //Alle Modellklassen im Ordner „application/models/“ laden
'application.components.*' , //Alle Anwendungskomponentenklassen im Ordner „application/components/“ laden
),
'defaultController'=>'post', //Standard-Controller-Klasse festlegen
// Die Komponentenkonfiguration der aktuellen Anwendung. Weitere Konfigurationskomponenten finden Sie unter „Kernanwendungskomponenten“ unten
'components'=>array(
'user'=>array( //user (user ) Komponentenkonfiguration, „Benutzer“ ist die Komponenten-ID
// Sie können Cookie-basierte Authentifizierung verwenden
'allowautologin' = & gt; true, // Automatische Anmeldung zulassen
),
'Cache ' = & gt; array( //Cache-Komponente
‐ , ' Weight'=>40), //Cache-Server 2
),
),
'db'=>array( //db (Datenbank) Komponentenkonfiguration, „db“ ist die Komponenten-ID
'connectionString' => 'sqlite:protected/data/blog.db', //DSN-Zeichenfolge zum Herstellen einer Verbindung mit der Datenbank
'tablePrefix' => 'tbl_', // Datentabellenpräfix
) ,
// Wenn Sie eine MySQL-Datenbank verwenden möchten, entkommentieren Sie bitte Folgendes:
'erRraRantion' = & gt;, // Wenn ein Fehler auftritt, wird es ausgeführt. Der Controller-Name und der Methodenname sind alle in Kleinbuchstaben geschrieben und durch Schrägstriche „/“
),
//URL-Routing-Manager
'urlManager'=>array(
getrennt 'urlFormat'=>'path', //URL-Format. Es werden zwei Formate unterstützt: das „Pfad“-Format (z. B. /path/to/EntryScript.php/name1/value1/name2/value2...) und das „Get“-Format (z. B. /path/to/EntryScript.php). ? Name1=Wert1&Name2=Wert2...). Bei Verwendung des „Pfad“-Formats müssen folgende Regeln festgelegt werden: id:d+>/
'posts/
),
),
), 'log'=> array( //Aufzeichnung
'class' = & gt; 'Clogrouter', // Die Klasse zur Verarbeitung der Datensatzinformationen
'Routes' = & GT; Array (
'class' = & gt; 'cfileLogroute ', //
'levels' = & gt; 'error, warning', // error level
),
// Wenn Sie die Fehleraufzeichnungsmeldung auf der Webseite anzeigen möchten, brechen Sie die Kommentare ab untenParameter der Anwendungsschicht
'params'=>require(dirname(__FILE__).'/params.php'),
);
Kernanwendungskomponenten:
Yii vordefiniert Eine Reihe von Kernanwendungskomponenten, die Funktionen bereitstellen, die in gängigen Webanwendungen verwendet werden. Beispielsweise wird die Anforderungskomponente verwendet, um Benutzeranfragen zu analysieren und Informationen wie URLs, Cookies usw. bereitzustellen. Durch die Konfiguration der Eigenschaften dieser Kernkomponenten können wir das Standardverhalten von Yii nahezu beliebig ändern.
Nachfolgend listen wir die von CWebApplication vordefinierten Kernkomponenten auf.
assetManager: CAssetManager – verwaltet die Freigabe privater Asset-Dateien.
authManager: CAuthManager – Verwaltet die rollenbasierte Zugriffskontrolle (RBAC).
cache: CCache – Bietet Daten-Caching-Funktionalität. Beachten Sie, dass Sie die tatsächliche Klasse angeben müssen (z. B. CMemCache, CDbCache). Andernfalls wird NULL zurückgegeben, wenn Sie auf diese Komponente zugreifen.
clientScript: CClientScript – verwaltet Client-Skripte (Javascripts und CSS).
coreMessages: CPhpMessageSource – stellt die Übersetzung der vom Yii-Framework verwendeten Kernnachrichten bereit.
db: CDbConnection – Stellt eine Datenbankverbindung bereit. Beachten Sie, dass Sie zur Verwendung dieser Komponente deren Eigenschaft „connectionString“ konfigurieren müssen.
errorHandler: CErrorHandler – Behandelt nicht erfasste PHP-Fehler und Ausnahmen.
Format: CFormatter – formatierte numerische Anzeige. Diese Funktion ist ab Version 1.1.0 verfügbar.
Nachrichten: CPhpMessageSource – Stellt Nachrichtenübersetzungen bereit, die in Yii-Anwendungen verwendet werden.
Anfrage: CHttpRequest – Stellt Informationen über die Anfrage des Benutzers bereit.
securityManager: CSecurityManager – Bietet sicherheitsbezogene Dienste wie Hashing und Verschlüsselung.
session: CHttpSession – Stellt sitzungsbezogene Funktionen bereit.
statePersister: CStatePersister – Stellt globale Zustandspersistenzmethoden bereit.
urlManager: CUrlManager – Bietet Funktionen zum Parsen und Erstellen von URLs.
Benutzer: CWebUser – Bietet Identifikationsinformationen des aktuellen Benutzers.
themeManager: CThemeManager – verwaltet Themen.
Um auf eine Anwendungskomponente zuzugreifen, verwenden Sie Yii::app()->ID der Komponente
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 Bearbeitungsaktion. 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 in Kleinbuchstaben geschrieben werden müssen.
Das Format des Routings: 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)
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 dem vom Benutzer angegebenen erstellt Die Controller-ID 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 404 CHttpException 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 er eine Anfrage erhält. Dadurch können Aktionen wiederverwendet werden, was die Wiederverwendbarkeit verbessert.
1. Definieren Sie eine Aktionsklasse wie folgt:
class UpdateAction erweitert CAction
{
public function 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
{
public function actions()
{
return array(
.php"-Datei zur Verarbeitung der Bearbeitungsaktion
);
}
}
Wie oben gezeigt, haben wir den Pfadalias „application.controllers.post.UpdateAction“ verwendet, um die Aktionsklassendatei „protected/controllers/post/UpdateAction.php“ anzugeben.
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 Aktualisierungsaktion. UpdateAction.php
4Ein 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)
{
// Logik wird angewendet, bevor die Aktion ausgeführt wird
Rückgabe true; // Wenn die Aktion nicht ausgeführt werden soll, geben Sie hier false zurück
}
protected function postFilter($filterChain)
{
// Logik wird angewendet, nachdem die Aktion ausgeführt wurde
}
}
Um Filter auf Aktionen anzuwenden, müssen wir die Methode CController::filters() überschreiben. Diese Methode sollte ein Array von Filterkonfigurationen zurückgeben. Zum Beispiel:
class PostController erweitert CController
{
...
public function filter()
{
return array(
'postOnly + edit, create' , / /Wenden Sie den PostOnly-Filter auf die Bearbeitungs- und Erstellungsaktionen an (dies ist ein methodenbasierter Filter)
array( //Ein Array wird verwendet, um den Filter zu konfigurieren , // Application.filters.perFormancefilter-Filter auf alle Optionen außer Bearbeiten anwenden und Erstellen (dies ist ein objektbasierter Filter)
'unit' = & gt; 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 mit einem Array, damit es 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, während PerformanceFilter auf andere Aktionen als Bearbeiten und Erstellen angewendet werden sollte. Wenn das Plus- oder Minuszeichen in der Filterkonfiguration nicht verwendet wird, wird dieser Filter auf alle Aktionen angewendet.
5. 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.
Ansichten haben einen Namen, der beim Rendern zur Identifizierung der Ansichtsskriptdatei verwendet wird. 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 erfordern.
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 übergeben, das die Initialisierungswerte dieser Eigenschaften trägt. Der Schlüssel des Arrays ist der Name der Eigenschaft, und der Wert des Arrays ist der Wert, der der Eigenschaft des kleinen Objekts entspricht. Wie unten gezeigt:
$this->widget('CMaskedTextField',array(
'mask'=>'99/99/9999'
));
?>
CWidget erben und seine init()- und run()-Methoden überschreiben, um ein neues Widget zu definieren:
class MyWidget erweitert CWidget
{
public function init()
{
// Diese Methode wird von CController::beginWidget() aufgerufen
}
public function run()
{
// Diese Methode wird von CController::endWidget() aufgerufen Durch Aufrufen von
}
}
kann ein Widget 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:
öffentliche Funktion getTextWidth() // Die textWidth-Eigenschaft abrufen
{
return $this->_textWidth;
}
public function setTextWidth($value) // Die TextWidth-Eigenschaft festlegen
{
$this->_textWidth=$value;
}
Der obige Code definiert eine beschreibbare Eigenschaft namens textWidth (bei dem Namen wird die Groß-/Kleinschreibung nicht berücksichtigt). 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ührung 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. Im letzteren Fall muss es als Array bereitgestellt werden: array($object,'methodName').
Die Struktur des Ereignishandles ist wie folgt:
Name der Funktionsmethode ($event)
{
...
}
$event hier ist der Parameter, der das Ereignis beschreibt ( es 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->handed auf true.
3. Komponentenverhalten
Die Komponente bietet zusätzliche Unterstützung für Mixin und kann ein oder mehrere Verhaltensweisen 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 Bindungseigenschaften 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. Nachfolgend eine typische Verzeichnisstruktur eines Fourm-Moduls:
Forum-/Modulordner
Moduldatei forummodule.php
Komponenten/enthält wiederverwendbare Benutzerkomponenten
Ansichten/enthält die Ansichtsdatei kleiner Objekte
Controller/Enthält Controller-Klassendatei
DefaultController.php Standard-Controller-Klassendatei
Erweiterungen/ Enthält Erweiterungen von Drittanbietern
Modelle/ Enthält Modellklassendateien
Ansichten/ Enthält Controller-Ansichts- und Layoutdateien
Layouts/ Enthält Layout files
default/ Enthält Ansichtsdateien für DefaultController
index.php Homepage-Ansichtsdateien
module Es muss eine Modulklasse vorhanden sein, die von CWebModule erbt. 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',... ) ,
...
);
Modul kann 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,
),
),
...
);
Instanzen von Modulen sind über die Moduleigenschaft des aktuell aktiven Controllers zugänglich. 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 auf die Controller-Instanz verwiesen wird, können Sie die folgende Anweisung verwenden
// $postPerPage=$this->module->postPerPage;
Auf die Controller-Aktionen im Modul kann über die Route „Modul-ID/Controller-ID/Aktions-ID“ oder „Modul-ID/Name des Unterverzeichnisses, in dem die Controller-Klassendatei gespeichert ist/Controller-ID/Aktions-ID“ zugegriffen werden. 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 bezeichnen wir als übergeordnetes Modul und letzteres als 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.
10. Entwicklungsspezifikationen
Nachfolgend erläutern wir die empfohlenen Entwicklungsspezifikationen in der Yii-Programmierung. Nehmen wir der Einfachheit halber an, dass WebRoot das Verzeichnis ist, in dem die Yii-Anwendung installiert ist.
1. URL
Standardmäßig erkennt Yii URLs im folgenden Format:
http://hostname/index.php?r=ControllerID/ActionID
Die r-Variable bedeutet Route. Es kann sein von Yii in Controller und Aktionen analysiert. Wenn ActionID weggelassen wird, verwendet der Controller die Standardaktion (definiert in CController::defaultAction); wenn ControllerID ebenfalls weggelassen wird (oder die r-Variable nicht vorhanden ist), verwendet die Anwendung den Standardcontroller (definiert in CWebApplication::defaultController). ).
Mit Hilfe von CUrlManager können Sie besser identifizierbare und SEO-freundliche URLs erstellen, wie zum Beispiel http://hostname/ControllerID/ActionID.html.
2. Code
Yii empfiehlt, bei der Benennung von Variablen, Funktionen und Klassen die Kamel-Schreibweise zu verwenden, d. h. der erste Buchstabe jedes Wortes wird großgeschrieben und miteinander verbunden, ohne Leerzeichen dazwischen. Bei Variablen- und Funktionsnamen sollte das erste Wort ausschließlich in Kleinbuchstaben geschrieben werden, um sie von Klassennamen zu unterscheiden. Für private Klassenmitgliedsvariablen empfehlen wir, ihren Namen einen Unterstrich voranzustellen (z. B. $_actionList).
Eine Sonderregel für Controller-Klassennamen ist, dass sie mit dem Wort Controller enden müssen. Dann ist die Controller-ID der erste Buchstabe des Klassennamens in Kleinbuchstaben und das Wort Controller wird entfernt. Die ID der PageController-Klasse lautet beispielsweise page. Diese Regel macht die Anwendung sicherer. Es vereinfacht auch Controller-bezogene URLs (z. B. /index.php?r=page/index statt /index.php?r=PageController/index).
3. Konfiguration
Konfiguration ist ein Array von Schlüssel-Wert-Paaren. Jeder Schlüssel stellt den Eigenschaftsnamen im konfigurierten Objekt dar und jeder Wert ist der Anfangswert der entsprechenden Eigenschaft.
Jede beschreibbare Eigenschaft in der Klasse kann konfiguriert werden. Wenn sie nicht konfiguriert sind, verwenden Eigenschaften ihre Standardwerte. Beim Konfigurieren einer Eigenschaft empfiehlt es sich, die Dokumentation zu lesen, um sicherzustellen, dass die Anfangswerte korrekt sind.
4. Dateien
Die Konventionen für die Benennung und Verwendung von Dateien hängen von ihrem Typ ab.
Klassendateien sollten nach den darin enthaltenen öffentlichen Klassen benannt werden. Die Klasse CController befindet sich beispielsweise in der Datei CController.php. Eine öffentliche Klasse ist eine Klasse, die von jeder anderen Klasse verwendet werden kann. Jede Klassendatei sollte höchstens eine öffentliche Klasse enthalten. Private Klassen (Klassen, die nur von einer öffentlichen Klasse verwendet werden können) können in derselben Datei abgelegt werden wie die öffentliche Klasse, die sie verwendet.
Ansichtsdateien sollten nach der Ansicht benannt werden. Die Indexansicht befindet sich beispielsweise in der Datei index.php. Eine Ansichtsdatei ist eine PHP-Skriptdatei, die den HTML- und PHP-Code enthält, der zum Rendern von Inhalten verwendet wird.
Die Konfigurationsdatei kann beliebig benannt werden. Eine Konfigurationsdatei ist ein PHP-Skript, dessen Hauptzweck darin besteht, ein assoziatives Array zurückzugeben, das die Konfiguration verkörpert.
5. Verzeichnis
Yii geht von einer Reihe von Standardverzeichnissen für verschiedene Situationen aus. Jedes Verzeichnis kann bei Bedarf angepasst werden.
WebRoot/protected: Dies ist das Basisverzeichnis der Anwendung, in dem alle sicherheitsrelevanten PHP-Skripte und Datendateien abgelegt werden. Yii verfügt über einen Standardanwendungsalias, der auf dieses Verzeichnis verweist. Dieses Verzeichnis und die darin enthaltenen Dateien sollten vor dem Zugriff von Webbenutzern geschützt werden. Es kann über CWebApplication::basePath angepasst werden.
WebRoot/protected/runtime: Dieses Verzeichnis enthält private temporäre Dateien, die generiert werden, wenn die Anwendung ausgeführt wird. Dieses Verzeichnis muss für den Webserverprozess beschreibbar sein. Es kann über CApplication::runtimePath angepasst werden.
WebRoot/protected/extensions: Dieses Verzeichnis enthält alle Erweiterungen von Drittanbietern. Es kann über CApplication::extensionPath angepasst werden.
WebRoot/protected/modules: In diesem Verzeichnis werden alle Anwendungsmodule abgelegt, und jedes Modul verwendet ein Unterverzeichnis.
WebRoot/protected/controllers: Dieses Verzeichnis enthält alle Controller-Klassendateien. Es kann über CWebApplication::controllerPath angepasst werden.
WebRoot/protected/views: Dieses Verzeichnis enthält alle Ansichtsdateien, einschließlich Controller-Ansichten, Layout-Ansichten und Systemansichten. Es kann über CWebApplication::viewPath angepasst werden.
WebRoot/protected/views/ControllerID: Dieses Verzeichnis platziert die verwendeten Ansichtsdateien in einer einzelnen Controller-Klasse. ControllerID bezieht sich hier auf die ID des Controllers. Es kann über CController::viewPath angepasst werden.
WebRoot/protected/views/layouts: Dieses Verzeichnis enthält alle Layout-Ansichtsdateien. Es kann über CWebApplication::layoutPath angepasst werden.
WebRoot/protected/views/system: Dieses Verzeichnis enthält alle Systemansichtsdateien. Systemansichtsdateien sind Vorlagen zur Anzeige von Ausnahmen und Fehlern. Es kann über CWebApplication::systemViewPath angepasst werden.
WebRoot/assets: In diesem Verzeichnis werden öffentliche Ressourcendateien abgelegt. Ressourcendateien sind private Dateien, die von Webbenutzern veröffentlicht und abgerufen werden können. Dieses Verzeichnis muss für den Webserverprozess beschreibbar sein. Es kann über CAssetManager::basePath
WebRoot/themes angepasst werden: In diesem Verzeichnis werden verschiedene von der Anwendung verwendete Designs abgelegt. Jedes Unterverzeichnis ist ein Thema und der Name des Themas ist der Name des Verzeichnisses. Es kann über CThemeManager::basePath angepasst werden.
6. Datenbank
Die meisten Webanwendungen werden von Datenbanken gesteuert. Wir empfehlen, bei der Benennung von Tabellen und Spalten die folgende Namenskonvention zu verwenden. Beachten Sie, dass diese Spezifikationen für Yii nicht erforderlich sind.
㈠Verwenden Sie Kleinbuchstaben für Datenbanktabellennamen und Spaltennamen.
Wörter im Namen sollten durch Unterstriche getrennt werden (z. B. Produktbestellung).
㈢Für Tabellennamen können Sie entweder den Singular oder den Plural verwenden. Aber verwenden Sie nicht beides gleichzeitig. Der Einfachheit halber empfehlen wir die Verwendung von Singularnamen.
Tabellennamen können ein gemeinsames Präfix verwenden, z. B. tbl_. Dies ist besonders nützlich, wenn die von einer Anwendung verwendete Tabelle in derselben Datenbank koexistiert wie eine von einer anderen Anwendung verwendete Tabelle. Die Tabellen dieser beiden Anwendungen können durch die Verwendung unterschiedlicher Tabellenpräfixe leicht unterschieden werden.
Ⅱ Verwendung von Formularen
Bei der Verarbeitung von Formularen in Yii sind normalerweise die folgenden Schritte erforderlich:
1. Erstellen Sie eine Modellklasse, um die zu sammelnden Datenfelder darzustellen.
2. Erstellen Sie eine Controller-Aktion, um auf die Formularübermittlung zu reagieren.
3. Erstellen Sie ein Formular, das sich auf die Controller-Aktion im Ansichtsskript bezieht.
1. Erstellen Sie ein Modell
Bevor wir den für das Formular erforderlichen HTML-Code schreiben, sollten wir zunächst die Art der Dateneingabe des Endbenutzers bestimmen und welchen Regeln die Daten entsprechen sollen. Zur Aufzeichnung dieser Informationen können Modellklassen verwendet werden. Wie im Kapitel „Modelle“ definiert, sind Modelle der zentrale Ort zum Speichern von Benutzereingaben und zum Validieren dieser Eingaben.
Je nachdem, wie die vom Benutzer eingegebenen Daten verwendet werden, können wir zwei Arten von Modellen erstellen. Wenn Benutzereingaben gesammelt, verwendet und dann verworfen werden, sollten wir ein Formularmodell erstellen. Wenn Benutzereingaben gesammelt und dann in einer Datenbank gespeichert werden, sollten wir einen aktiven Datensatz verwenden. Beide Modelltypen nutzen dieselbe Basisklasse CModel , die die für das Formular erforderliche gemeinsame Schnittstelle definiert.
1. Definieren Sie die Modellklasse
Erstellen Sie beispielsweise ein Formularmodell:
class LoginForm erweitert CFormModel
{
public $username;
public $password;
public $ RememberMe= false;
}
In LoginForm sind drei Eigenschaften definiert: $username, $password und $rememberMe. Sie dienen dazu, den vom Benutzer eingegebenen Benutzernamen und das Passwort zu speichern und bieten auch die Möglichkeit, dass der Benutzer sich sein Login merken möchte. Da $rememberMe den Standardwert „false“ hat, wird die entsprechende Option bei der ersten Anzeige im Anmeldeformular deaktiviert.
Wir nennen diese Mitgliedsvariablen Attribute statt Eigenschaften, um sie von gewöhnlichen Eigenschaften zu unterscheiden. Ein Attribut ist eine Eigenschaft, die hauptsächlich zum Speichern von Daten aus Benutzereingaben oder Datenbanken verwendet wird.
2. Validierungsregeln deklarieren
Sobald der Benutzer seine Eingabe übermittelt und das Modell ausgefüllt ist, müssen wir vor der Verwendung sicherstellen, dass die Eingabe des Benutzers gültig ist. Dies wird durch die Validierung der Benutzereingaben anhand einer Reihe von Regeln erreicht. Wir geben diese Validierungsregeln in der Methode Rules() an, die ein Array von Regelkonfigurationen zurückgeben soll.
class LoginForm erweitert CFormModel
{
public $username;
public $password;
public $rememberMe=false;
private $_identity;
öffentliche Funktionsregeln()
{
return array(
array('username, password', 'required'), //Benutzername und Passwort sind erforderlich
array('rememberMe', ' boolean' ), //rememberMe sollte ein boolescher Wert sein
array('password', 'authenticate'), //das Passwort sollte authentifiziert werden
);
}
public functionauthenticate($ attribute,$params)
{
$this->_identity=new UserIdentity($this->username,$this->password);
if(!$this ->_identity- >authenticate())
Jede von Rules() zurückgegebene Regel muss das folgende Format haben:
array('AttributeList', 'Validator', 'on'=>'ScenarioList', ... zusätzlich Optionen)
wobei:
AttributeList eine Zeichenfolge von Attributlisten ist, die durch diese Regel überprüft werden müssen;
Validator (Validator) gibt die Art der durchzuführenden Überprüfung an; Der
on-Parameter ist optional. Er gibt eine Liste von Szenarien an, auf die diese Regel angewendet werden soll.
Zusätzliche Optionen sind ein Array von Name-Wert-Paaren, die zum Initialisieren der entsprechenden Validator-Attributwerte verwendet werden.
Es gibt drei Möglichkeiten, Validator in Validierungsregeln anzugeben:
Erstens kann Validator der Name einer Methode in der Modellklasse sein, wie Authenticate im obigen Beispiel. Die Validierungsmethode muss die folgende Struktur haben:
Name des öffentlichen Funktionsvalidators ($attribute, $params) { ... }
Zweitens kann Validator der Name einer Validatorklasse sein, wenn diese Regel gilt angewendet, wird eine Instanz der Validator-Klasse erstellt, um die eigentliche Validierung durchzuführen. Zusätzliche Optionen in den Regeln werden verwendet, um die Attributwerte der Instanz zu initialisieren. Validator-Klassen müssen von CValidator erben.
Drittens kann Validator ein Alias einer vordefinierten Validator-Klasse sein. Im obigen Beispiel ist der erforderliche Name ein Alias für CRequiredValidator, der verwendet wird, um sicherzustellen, dass die zu validierende Eigenschaft nicht leer ist. Hier ist die vollständige Liste der vordefinierten Validator-Aliase:
boolean: Alias für CBooleanValidator, der sicherstellt, dass das Attribut einen CBooleanValidator::trueValue- oder CBooleanValidator::falseValue-Wert hat.
Captcha: Alias für CCaptchaValidator, stellt sicher, dass der Attributwert dem im CAPTCHA angezeigten Bestätigungscode entspricht.
compare: Alias für CCompareValidator, der sicherstellt, dass eine Eigenschaft einer anderen Eigenschaft oder Konstante entspricht.
E-Mail: Alias für CEmailValidator, um sicherzustellen, dass das Attribut eine gültige E-Mail-Adresse ist.
Standard: Alias von CDefaultValueValidator, der den Standardwert des Attributs angibt.
exist: Alias für CExistValidator, der sicherstellt, dass Attributwerte in Spalten der angegebenen Tabelle gefunden werden können.
Datei: Alias für CFileValidator. Stellen Sie sicher, dass das Attribut den Namen einer hochgeladenen Datei enthält.
Filter: Alias von CFilterValidator, ändern Sie diese Eigenschaft durch einen Filter.
in: Alias für CRangeValidator, der sicherstellt, dass die Daten innerhalb eines vorab festgelegten Wertebereichs liegen.
Länge: Alias von CStringValidator, der sicherstellt, dass die Länge der Daten innerhalb eines angegebenen Bereichs liegt.
match: Alias von CRegularExpressionValidator, um sicherzustellen, dass die Daten mit einem regulären Ausdruck übereinstimmen können.
numerisch: Alias von CNumberValidator, der sicherstellt, dass die Daten eine gültige Zahl sind.
erforderlich: Alias für CRequiredValidator, um sicherzustellen, dass das Attribut nicht leer ist.
Typ: Alias für CTypeValidator, um sicherzustellen, dass das Attribut vom angegebenen Datentyp ist.
unique: Alias von CUniqueValidator, der sicherstellt, dass die Daten unter den Spalten in der Datentabelle eindeutig sind.
URL: Alias von CUrlValidator, der sicherstellt, dass die Daten eine gültige URL sind.
Im Folgenden listen wir einige Beispiele auf, die nur diese vordefinierten Validatoren verwenden:
// Benutzername ist erforderlich
array('username', 'required'),
// Benutzername muss zwischen 3 und 3 liegen und 12 Zeichen
array('username', 'length', 'min'=>3, 'max'=>12),
// in Im Registrierungsszenario muss das Passwort konsistent sein mit Passwort2.
array('password', 'compare', 'compareAttribute'=>'password2', 'on'=>'register'),
// Im Anmeldeszenario muss das Passwort überprüft werden.
array('password', 'authenticate', 'on'=>'login'),
3. Sichere Attributzuweisung
Nachdem eine Instanz einer Klasse erstellt wurde, führen wir normalerweise „It Eigenschaften müssen mit vom Endbenutzer übermittelten Daten gefüllt werden. Dies kann leicht mit der folgenden umfangreichen Zuweisung erreicht werden:
$model=new LoginForm;
if(isset($_POST['LoginForm']))
$model->attributes=$ _POST[' LoginForm'];
Der letzte Ausdruck wird als massive Zuweisung bezeichnet, die jedes Element in $_POST['LoginForm'] in das entsprechende Modellattribut kopiert. Dies entspricht der folgenden Zuweisungsmethode:
foreach($_POST['LoginForm'] as $name=>$value)
{
if($name is a secure feature)
$ model ->$name=$value;
}
Die Sicherheit der Erkennungsfunktionen ist sehr wichtig, wenn wir beispielsweise den Primärschlüssel einer Tabelle offenlegen und denken, dass er sicher ist, kann der Angreifer eine Änderung erhalten Aufzeichnung des Primärschlüssels, wodurch Inhalte manipuliert werden, die für ihn nicht autorisiert sind.
Eine Funktion gilt als sicher, wenn sie in einer Validierungsregel im entsprechenden Szenario vorkommt. Zum Beispiel:
array('Benutzername, Passwort', 'erforderlich', 'on'=>'Anmelden, Registrieren'),
array('E-Mail', 'erforderlich', 'on'=> ' registrieren'),
Wie oben gezeigt, sind die Attribute Benutzername und Passwort im Anmeldeszenario erforderlich. Im Registrierungsszenario sind die Attribute Benutzername, Passwort und E-Mail erforderlich. Wenn wir also im Anmeldeszenario eine Blockzuweisung durchführen, werden nur Benutzername und Passwort blockiert. Weil sie die einzigen sind, die in den Validierungsregeln des Logins erscheinen. Handelt es sich hingegen um ein Registerszenario, können alle drei Eigenschaften blockweise zugewiesen werden.
// Im Anmeldeszenario
$model=new User('login');
if(isset($_POST['User']))
$model->attributes=$ _POST['User'];
// Im Registrierungsszenario
$model=new User('register');
if(isset($_POST['User']))
$ model->attributes=$_POST['User'];
Warum verwenden wir also eine solche Strategie, um zu erkennen, ob Attribute sicher sind? Der Grundgedanke dahinter ist: Wenn ein Feature bereits über eine oder mehrere Validierungsregeln verfügt, die die Gültigkeit erkennen können, worüber müssen wir uns dann Sorgen machen?
Denken Sie daran, dass Validierungsregeln verwendet werden, um die vom Benutzer eingegebenen Daten zu überprüfen, nicht die Daten, die wir im Code generiert haben (z. B. Zeitstempel, automatisch generierter Primärschlüssel). Fügen Sie daher keine Validierungsregeln für Funktionen hinzu, die keine Endbenutzereingaben akzeptieren.
Manchmal möchten wir eine Funktion als sicher deklarieren, auch wenn wir keine Regeln dafür festlegen. Beispielsweise kann der Inhalt eines Artikels jede Eingabe des Benutzers akzeptieren. Wir können dies mithilfe einer speziellen sicheren Regel tun:
array('content', 'safe')
Es gibt auch eine unsichere Regel, um eine Eigenschaft als unsicher zu deklarieren:
array('permission' , 'unsafe') )
Die unsichere Regel wird nicht häufig verwendet und stellt eine Ausnahme von den Sicherheitseigenschaften dar, die wir zuvor definiert haben.
4. Validierung auslösen
Sobald das Modell mit vom Benutzer übermittelten Daten gefüllt ist, können wir CModel::validate() aufrufen, um den Datenvalidierungsprozess auszulösen. Diese Methode gibt einen Wert zurück, der angibt, ob die Überprüfung erfolgreich war. Bei CActiveRecord-Modellen kann die Validierung auch automatisch ausgelöst werden, wenn wir die Methode CActiveRecord::save() aufrufen.
Wir können die Szenarioeigenschaften festlegen, indem wir das Szenarioattribut festlegen, sodass die Validierungsregeln des entsprechenden Szenarios angewendet werden.
Die Validierung erfolgt szenariobasiert. Das Szenarioattribut gibt das Szenario an, in dem das Modell derzeit verwendet wird, und den aktuell verwendeten Satz von Validierungsregeln. Im Anmeldeszenario möchten wir beispielsweise nur die Eingaben von Benutzername und Passwort im Benutzermodell validieren, während wir im Registerszenario weitere Eingaben wie E-Mail, Adresse usw. validieren müssen. Das folgende Beispiel zeigt, wie die Validierung im Registrierungsszenario durchgeführt wird:
// Erstellen Sie ein Benutzermodell im Registrierungsszenario. Entspricht:
// $model=new User;
// $model->scenario='register';
$model=new User('register'); //Geben Sie die Modellklasse an Fügen Sie einen Parameter hinzu, der das auszulösende Überprüfungsszenario darstellt
// Geben Sie den Eingabewert in das Modell ein
$model->attributes=$_POST['User'];
//Validierung durchführen
if($model->validate()) // Wenn die Eingabe gültig ist
...
sonst
...
Das mit der Regel verknüpfte Szenario kann über die Option „on“ in der Regel angegeben werden. Wenn die Option „Ein“ nicht festgelegt ist, gilt diese Regel für alle Szenarios. Zum Beispiel:
public function Rules()
{
return array(
array('username, password', 'required'),
array('password_repeat', 'required', ' on'=>'register'),
array('password', 'compare', 'on'=>'register'),
);
}
Die erste Regel gilt für alle Szenarien, während das zweite nur für das Registerszenario gilt.
5. Verifizierungsfehler extrahieren
Nach Abschluss der Verifizierung werden eventuell auftretende Fehler im Modellobjekt gespeichert. Wir können diese Fehlermeldungen extrahieren, indem wir CModel::getErrors() und CModel::getError() aufrufen. Der Unterschied zwischen diesen beiden Methoden besteht darin, dass die erste Methode Fehlerinformationen für alle Modelleigenschaften zurückgibt, während die zweite Methode nur Fehlerinformationen für die erste zurückgibt.
6. Funktionsbeschriftungen
Beim Entwerfen eines Formulars müssen wir normalerweise für jedes Formularfeld eine Beschriftung anzeigen. Die Beschriftung teilt dem Benutzer mit, welche Informationen er in dieses Formularfeld eintragen soll. Obwohl wir eine Beschriftung in der Ansicht fest codieren können, ist es flexibler und bequemer, wenn wir (die Beschriftung) im entsprechenden Modell angeben.
Standardmäßig gibt CModel einfach den Namen des Attributs als Beschriftung zurück. Dies kann durch Überschreiben der attributeLabels()-Methode angepasst werden. Wie wir im nächsten Abschnitt sehen werden, können wir durch die Angabe von Tags im Modell schneller leistungsfähigere Formulare erstellen.
2. Aktionen erstellen
Mit dem vorliegenden Modell können wir mit dem Schreiben der Logik für den Betrieb dieses Modells beginnen. Wir setzen diese Logik in eine Controller-Aktion ein. Für das Anmeldeformular-Beispiel lautet der entsprechende Code:
public function actionLogin()
{
$model=new LoginForm;
if(isset($_POST['LoginForm']))
{
// Vom Benutzer eingegebene Daten sammeln
$model->attributes=$_POST['LoginForm'];
// Benutzereingaben überprüfen und zur vorherigen Seite weiterleiten
if($model ->validate())
$this->redirect(Yii::app()->user->returnUrl); //Erforderlich vor der Weiterleitung zur Authentifizierungsseiten-URL
}
/ / Anmeldeformular anzeigen
$this->render('login',array('model'=>$model));
}
Wie oben gezeigt, erstellen wir zunächst ein Anmeldeformular Modellbeispiel; wenn es sich bei der Anfrage um eine POST-Anfrage handelt (was bedeutet, dass das Anmeldeformular gesendet wird), verwenden wir die übermittelten Daten $_POST['LoginForm'], um $model zu füllen; dann validieren wir diese Eingabe und, wenn die Validierung erfolgreich ist, Leiten Sie den Browser des Benutzers auf die Seite um, für die zuvor eine Authentifizierung erforderlich war. Wenn die Überprüfung fehlschlägt oder auf diese Aktion zum ersten Mal zugegriffen wird, rendern wir die Anmeldeansicht. Der Inhalt dieser Ansicht wird im nächsten Abschnitt erläutert.
Tipp: Bei der Anmeldeaktion verwenden wir Yii::app()->user->returnUrl, um die Seiten-URL abzurufen, für die zuvor eine Authentifizierung erforderlich war. Die Komponente Yii::app()->user ist ein CWebUser (oder seine Unterklasse), der Benutzersitzungsinformationen (z. B. Benutzername, Status) darstellt.
Lassen Sie uns besonderes Augenmerk auf die folgende PHP-Anweisung legen, die in der Anmeldeaktion erscheint:
$model->attributes=$_POST['LoginForm'];
Wie wir in Safe Attribute Assignment gesagt haben, ist dies Die Codezeile füllt das Modell mit vom Benutzer übermittelten Daten. Die Eigenschaft attributes wird von CModel definiert, das ein Array von Name-Wert-Paaren akzeptiert und jeden Wert dem entsprechenden Modellattribut zuweist. Wenn uns also $_POST['LoginForm'] ein Array wie dieses liefert, entspricht der obige Code dem folgenden langen Absatz (vorausgesetzt, alle erforderlichen Funktionen sind im Array vorhanden):
$model-> ;username=$ _POST['LoginForm']['username'];
$model->password=$_POST['LoginForm']['password'];
$model->rememberMe=$ _POST['LoginForm ']['rememberMe'];
Hinweis: Damit $_POST['LoginForm'] uns ein Array anstelle einer Zeichenfolge übergibt, müssen wir bei der Benennung von Formularfeldern eine Konvention befolgen. Insbesondere nennen wir das Formularfeld, das dem Merkmal a in der Modellklasse C entspricht, C[a]. Beispielsweise können wir LoginForm[Benutzername] verwenden, um das Formularfeld zu benennen, das dem Benutzernamensattribut entspricht.
Jetzt müssen Sie nur noch die Login-Ansicht erstellen, die ein HTML-Formular mit den erforderlichen Eingaben enthalten sollte.
三、创建表单
编写 login 视图是很简单的，我们以一个 form 标记开始，它的 action 属性应该是前面讲述的 login 动作的URL。然后我们需要为 LoginForm 类中声明的属性插入标签和表单域。最后，我们插入一个可由用户点击提交此表单的提交按钮。所有这些都可以用纯HTML代码完成。
Yii 提供了几个助手（helper）类简化视图编写。例如，要创建一个文本输入域，我们可以调用 CHtml::textField()；要创建一个下拉列表，则调用 CHtml::dropDownList()。
例如， 如下代码将生成一个文本输入域，它可以在用户修改了其值时触发表单提交动作。
CHtml::textField($name,$value,array('submit'=>''));
下面，我们使用 CHtml 创建一个登录表单。我们假设变量 $model 是 LoginForm 的实例。
| Name< ;/th> | Preis | Anzahl | Beschreibung |
|---|---|---|---|
