Erstellen von Form Elementen mit Hilfe von Zend_Form_ElementEin Formular ist aus Elementen gemacht, die typischerweise mit einer HTML Form Eingabe korrespondieren. Zend_Form_Element kapselt einzelne Formularelemente mit den folgenden Bereichen die erfüllt werden sollen:
Die Basisklasse, Zend_Form_Element, hat begründete Standardwerte für viele Fälle, aber es ist am besten die Klasse zu erweitern für oft verwendete speziell benötigte Elemente. Zusätzlich wird Zend Framework mit einer Anzahl an Standard XHTML Elementen ausgeliefert; über diese kann im Kapitel über Standard Elemente nachgelesen werden. Plugin LoaderZend_Form_Element verwendet Zend_Loader_PluginLoader um es Entwicklern zu erlauben Orte für alternative Prüfungen, Filter und Dekoratoren zu definieren. Jeder hat seinen eigenen Plugin Loader assoziiert, und generelle Zugriffspunkte werden verwendet um jeden zu empfangen oder zu ändern. Die folgenden Ladetypen werden mit den verschiedenen Plugin Loader Methoden verwendet: 'validate', 'filter', und 'decorator'. Die Typnamen sind unabhängig von der Schreibweise. Die Methoden die für die Interaktion mit Plugin Loadern verwendet werden, sind die folgenden:
Eigene Prüfungen, Filter und Dekoratoren sind ein einfacher Weg um Funktionalität zwischen Forms zu teilen und eigene Funktionalitäten zu kapseln. Example #1 Eigenes Label Ein üblicher Verwendungszweck ist es Ersetzungen für Standardklassen anzubieten. Zum Beispiel wenn man eine andere Implementation des 'Label' Dekorators anbieten will -- zum Beispiel um immer einen Bindestrich anzufügen -- dann könnte man einen eigenen 'Label' Dekorator mit einem eigenen Klassenpräfix erstellen, und diesen zum eigenen Präfix Pfad hinzufügen. Beginnen wir mit einem eigenen Label Dekorator. Wir geben ihm den Klassenpräfix "My_Decorator", und die Klasse selbst wird in der Datei "My/Decorator/Label.php" sein.
Jetzt kann dem Element mitgeteilt werden diesen Plugin Pfad zu verwenden wenn nach Dekoratoren gesucht wird:
Alternativ kann das bei der Form gemacht werden um sicherzustellen das alle Dekoratore diesen Pfad verwenden:
Wird dieser Pfad hinzugefügt, wenn ein Dekorator hinzugefügt wird, wird der Pfad 'My/Decorator/' zuerst durchsucht um zu sehen ob der Dekorator dort existiert. Als Ergebnis wird 'My_Decorator_Label' jetzt verwendet wenn der 'Labe' Dekorator angefragt wird. FilterEs ist oft nützlich und/oder notwendig einige Normalisierungen an Eingaben vorzunehmen, bevor diese geprüft werden - zum Beispiel kann es gewünscht sein alles an HTML zu entfernen, aber die Prüfungen auf dem verbleibenden durchzuführen um sicherzustellen, dass die Übertragung gültig ist. Oder man will Leerzeichen bei Eingaben entfernen, damit eine StringLength Prüfung kein falsches "Korrekt" zurückgibt. Diese Operationen können durchgeführt werden indem Zend_Filter verwendet wird, und Zend_Form_Element unterstützt Filterketten, was es erlaubt mehrere, sequentielle Filter zu spezifizieren und anzupassen. Das Filtern geschieht während der Prüfung und wenn der Wert des Elements über getValue() geholt wird:
Filter können der Kette auf zwei Wegen hinzugefügt werden:
Sehen wir uns einige Beispiele an:
Kurznamen sind typischerweise der Filtername ohne den Präfix. Im Standardfall bedeutet das keinen 'Zend_Filter_' Präfix. Zusätzlich muss der erste Buchstabe nicht großgeschrieben werden.
Wenn man zu irgendeiner Zeit den ungefilterten Wert benötigt, kann die getUnfilteredValue() Methode verwendet werden:
Für weitere Informationen über Filter, siehe die Dokumentation über Zend_Filter. Die Methoden die mit Filtern assoziiert sind, beinhalten:
PrüfungenWenn man das Sicherheits-Mantra von "Eingabe filtern, Ausgabe escapen" unterschreibt dann wird man die Eingabe des Formulars prüfen ("Eingabefilterung") wollen. In Zend_Form enthält jedes Element seine eigene Prüfkette, die aus Zend_Validate_* Prüfungen besteht. Prüfungen können der Kette auf zwei Wegen hinzugefügt werden:
Einige Beispiele:
Kurznamen sind typischerweise der Prüfname ohne den Präfix. Im Standardfall bedeutet das, keinen 'Zend_Validate_' Präfix. Zusätzlich muss der erste Buchstabe nicht großgeschrieben werden.
Wenn eine bestimmte Prüfung fehlschlägt, und die Ausführung von späteren Prüfungen verhindert werden soll, kann ein TRUE als zweiter Parameter übergeben werden:
Wenn ein Stringname verwendet wird, um eine Prüfung hinzuzufügen und die Prüfklasse Argumente in ihrem Konstruktor akzeptiert, können diese als dritter Parameter an addValidator() als Array übergeben werden: Argumente die auf diesem Weg übergeben werden, sollten in der Reihenfolge sein in der sie im Konstruktor definiert sind. Das obige Beispiel instanziert die Zend_Validate_StringLenth Klasse mit den $min und $max Parametern:
Es können auch viele Prüfungen auf einmal gesetzt werden, indem addValidators() verwendet wird. Die grundsätzliche Verwendung ist es ein Array von Arrays zu übergeben, wobei jedes Array ein bis drei Werte enthält, die dem Konstruktor von addValidator() entsprechen: Wenn man wortreicher oder expliziter sein will, dann können die Arrayschlüssel 'validator', 'breakChainOnFailure', und 'options' verwendet werden: Die Verwendung ist gut für die Illustration wie Prüfungen in einer Konfigurationsdatei definiert werden können:
Es ist zu beachten, dass jedes Element einen Schlüssel hat, egal ob er benötigt wird oder nicht; das ist eine Einschränkung bei der Verwendung von Konfigurationsdateien -- aber es macht auch klar, für was die Argumente stehen. Es ist einfach zu beachten das jede Prüfungsoption in der richtigen Reihenfolge spezifiziert werden muss. Um ein Element zu prüfen, muss der Wert an isValid() übergeben werden:
Prüfungen werden in der Reihenfolge ausgeführt. Jede Prüfung wird ausgeführt solange bis eine Prüfung die mit einem TRUE Wert für $breakChainOnFailure bei Ihrer Prüfung fehlschlägt. Man sollte sichergehen, dass Prüfungen in einer begründeten Reihenfolge definiert werden. Nach einer fehlgeschlagenen Prüfung können Fehlercodes und Nachrichten von der Prüfkette empfangen werden:
(Achtung: zurückgegebene Fehlermeldungen sind ein assoziatives Array von Fehlercode/Fehlermeldung Paaren.) Zusätzlich zu Prüfungen, kann spezifiziert werden, dass ein Element benötigt wird, indem setRequired($flag) verwendet wird. Standardmäßig ist dieses Flag FALSE. In Kombination mit setAllowEmpty($flag) (Standardmäßig TRUE) und setAutoInsertNotEmptyValidator($flag) (standardmäßig TRUE), kann das Verhalten der Prüfkette auf unterschiedliche Art und Weise verändert werden:
Für weitere Informationen über Prüfungen kann in die Zend_Validate Dokumentation gesehen werden.
Die mit der Prüfung assoziierten Methoden sind:
Eigene FehlermeldungenVon Zeit zu Zeit ist es gewünscht ein oder mehrere spezielle Fehlermeldungen zu spezifizieren, die statt der Fehlermeldungen verwendet werden sollen, die von den Validatoren verwendet werden, die dem Element angehängt sind. Zusätzlich will man von Zeit zu Zeit ein Element selbst als ungültig markieren. Ab Version 1.6.0 des Zend Frameworks ist diese Funktionalität über die folgenden Methoden möglich.
Alle Fehler die auf diesem Weg gesetzt werden, können übersetzt werden. Zusätzlich kann der Platzhalter "%value%" eingefügt werden um den Wert des Elements zu repräsentieren; dieser aktuelle Wert des Element wird eingefügt wenn die Fehlermeldung empfangen wird. DekoratorenEin möglicher Schmerzpunkt für viele Webentwickler, ist die Erstellung von XHTML Formularen selbst. Für jedes Element muss der Entwickler das Markup für das Element selbst erstellen, typischerweise ein Label und, wenn sie nett zu den Benutzern sind, das Markup für die Anzeige von Fehlermeldungen von Prüfungen. Je mehr Elemente auf einer Seite sind, desto weniger trivial wird diese Aufgabe. Zend_Form_Element versucht dieses Problem durch die Verwendung von "Dekoratoren" zu lösen. Dekoratoren sind Klassen die Zugriff auf das Element haben und eine Methode zur Darstellung des Inhalts bieten. Für weitere Informationen darüber wie Dekoratoren arbeiten, kann im Kapitel über Zend_Form_Decorator eingesehen werden. Die von Zend_Form_Element verwendeten Standarddekoratoren sind:
Da die Reihenfolge, in der die Dekoratoren registriert werden, von Bedeutung ist -- der zuerst registrierte Dekorator wird als erstes ausgeführt -- muss man sicherstellen, dass eigene Dekoratoren in der richtigen Reihenfolge registriert werden, oder sicherstellen, dass die Platzierungs-Optionen in einem ausgewogenen Weg gesetzt werden. Um ein Beispiel zu geben, ist hier ein Code der den Standarddekorator registriert: Der anfängliche Inhalt wird vom 'ViewHelper' Dekorator erstellt, welche das Formular Element selbst erstellt. Als nächstes fängt der 'Errors' Dekorator Fehlermeldungen vom Element und, wenn welche vorhanden sind, übergibt er sie an den 'FormErrors' View Helfer zur Darstellung. Wenn eine Beschreibung vorhanden ist, wird der 'Description' Dekorator einen Paragraph der Klasse 'description' anhängen, der den beschreibenden Text für den betreffenden Inhalt enthält. Der nächste Dekorator, 'HtmlTag', umschliesst das Element und die Fehler in ein HTML <dd> Tag. Letztendlich, empfängt der letzte Dekorator, 'label' das Label des Elements und übergibt es an den 'FormLabel' View Helfer, und umschliesst es in einen HTML <dt> Tag; der Wert wird dem Inhalt standardmäßig vorangestellt. Die resultierende Ausgabe sieht grundsätzlich wie folgt aus:
Für weitere Informationen über Dekoratoren gibt es das Kapitel über Zend_Form_Decorator.
Die folgenden Methoden sind mit Dekoratoren assoziiert:
Zend_Form_Element verwendet auch Überladung um die Darstellung von speziellen Dekoratoren zu erlauben. __call() interagiert mit Methoden auf mit dem Text 'render' anfangen und verwendet den Rest des Methodennamens dazu um nach einen Dekorator zu suchen; wenn er gefunden wird, wird er diesen einzelnen Dekorator darstellen. Jedes Argument das dem Methodenaufruf übergeben wird, wird als Inhalt für die Übergabe an die render() Methode des Dekorators verwendet. Als Beispiel: Wenn der Dekorator nicht existiert, wird eine Exception geworfen. Metadaten und AttributeZend_Form_Element behandelt eine Vielzahl von Attributen und Metadaten des Elements. Basisattribute sind:
Formular Elemente können zusätzliche Metadaten benötigen. Für XHTML Form Elemente zum Beispiel, kann es gewünscht sein, Attribute wie die Klasse oder die Id zu spezifizieren. Für die Durchführung gibt es ein Set von Zugriffsmethoden:
Die meiste Zeit kann auf sie, trotzdem, einfach als Objekteigenschaften zugegriffen werden, da Zend_Form_Element das Überladen realisiert und den Zugriff zu ihnen erlaubt:
Standardmäßig werden alle Attribute, die an den View Helfer übergeben werden, auch vom Element während der Darstellung verwendet, und als HTML Attribute des Element Tags dargestellt. Standard ElementeZend_Form wird mit einer Anzahl an Standardelementen ausgeliefert; lesen Sie das Kapitel über Standard Elemente für vollständige Details. Zend_Form_Element MethodenZend_Form_Element hat viele, viele Methoden. Was folgt, ist eine kurze Zusammenfassung ihrer Signatur - gruppiert nach Typ:
KonfigurationDer Konstruktor von Zend_Form_Element akzeptiert entweder einen Array von Optionen oder ein Zend_Config Objekt das Optionen enthält, und es kann auch durch Verwendung von setOptions() oder setConfig() konfiguriert werden. Generell, werden die Schlüssel wie folgt benannt:
Ausnahmen zu dieser Regel sind die folgenden:
Als Beispiel ist hier eine Konfigurationsdatei die eine Konfiguration für jeden Typ von konfigurierbaren Daten übergibt:
Eigene ElementeEs können eigene Elemente durch die Erweiterung der Zend_Form_Element Klasse erstellt werden. Übliche Gründe hierfür sind:
Es gibt zwei Methoden die typischerweise verwendet werden, um ein Element zu erweitern: init(), was verwendet werden kannm um eine eigene Initialisierungs-Logik zum Element hinzuzufügen, und loadDefaultDecorators(), was verwendet werden kann um eine Liste von Standard Dekoratoren zu setzen, die vom Element verwendet werden sollen. Als Beispiel nehmen wir an, dass alle Text Elemente eines Formulars die erstellt werden mit StringTrim gefiltert werden müssen, mit einem gemeinsamen Regulären Ausdruck und das ein eigener Dekorator 'My_Decorator_TextItem' verwendet werden soll, der für die Darstellung von ihnen erstellt wurde; zusätzlich gibt es eine Anzahl an Standardattributen, wie 'size', 'maxLength', und 'class', die spezifiziert werden sollen. So ein Element könnte wie folgt definiert werden:
Man könnte dann das Formular Objekt über den Präfix Pfad für diese Elemente informieren, und die Erstellung der Elemente beginnen:
Das 'foo' Element wird vom Typ My_Element_Text sein, und dem beschriebenen Verhalten entsprechen. Eine andere Methode, die man überschreiben sollte, wenn Zend_Form_Element erweitert wird, ist die loadDefaultDecorators() Methode. Diese Methode lädt fallweise ein Set von Standarddekoratoren für das Element; es kann gewünscht sein, eigene Dekoratoren in der erweiterten Klasse zu verwenden:
Es gibt viele Wege, Elemente anzupassen; man sollte sicherstellen die API Dokumentation von Zend_Form_Element zu lesen um alle vorhandenen Methoden zu kennen.
|
|