DynaActionForm
DynaActionForm bietet einen praktischen Mechanismus, der das Schreiben einer ActionForm im Wesentlichen überflüssig macht. DynaActionForm ermöglicht dynamische Formulareigenschaften. Das bedeutet, dass Sie Eigenschaften in Ihrer Datei struts-config.xml definieren und den Formulartyp auf org.apache.struts.action.DynaActionForm festlegen können. Es muss nichts geschrieben werden. DynaActionForm verwendet DynaBean aus dem öffentlichen Apache-Projekt, um diese Vorgänge abzuschließen. Dieses dynamische Verhalten wird durch Reflektion und Hashmaps bereitgestellt.
DynaActionForm wird in der Datei struts-config.xml mithilfe von Tags wie folgt definiert:
Eigenschaften dynamischer Formulare ähneln Standard-ActionForm-Eigenschaften. Der Attributname wird zum Indizieren des Formular-Beans in der Aktion verwendet, und der Typ wird zum Angeben der instanziierten Klasse verwendet. Bei Verwendung der Klasse DynaActionForm werden die dynamischen Eigenschaften automatisch standardmäßig auf „true“ gesetzt. Bei DynaActionForm werden alle Eigenschaften des Formulars über Elemente spezifiziert. Der Name im Element bezieht sich auf den Attributnamen. Typ bezieht sich auf den Klassennamen der Java-Implementierungsklasse des Bean-Attributs. Wenn dieses Attribut vom Indextyp ist, fügen Sie nach dem Typ „[ ]“ hinzu. In der obigen Tabelle sollten Sie auf die Definition des letzten Attributs „Genre“ achten. Wir setzen den Anfangswert (oder Standardwert) auf „Tanz“. Dieser Wert wird auch als Standardwert festgelegt, wenn die Methode „reset()“ in DynaActionForm aufgerufen wird, und ermöglicht einen Mechanismus zum Festlegen von Standardwerten im Formular. Wenn im Anfangsattribut kein Wert angegeben ist, wird der Anfangswert aller primitiven Typen auf 0 gesetzt, wenn es sich um ein Objekt handelt, ist der Anfangswert null (leer).
Die Verwendung von DynaActionForm ist sehr praktisch. Einer der Hauptvorteile besteht darin, dass Sie nur sehr wenig Code schreiben müssen. Genau wie bei anderen Formularen enthält das vorangehende Codebeispiel den gesamten Code, den Sie zur Verwendung des Formulars benötigen. Eine Sache, die Sie wissen sollten, ist die Validierung. Bei Verwendung von DynaActionForm wird davon ausgegangen, dass die Validierungsverarbeitung irgendwo erfolgt, was sich etwas von ActionForm unterscheidet. Sie können die Validierung in Ihrer eigenen Aktion implementieren, dies ist jedoch ein besserer Ansatz.
Zur Überprüfung können Sie DynaValidatorForm oder DynaValidatorActionForm verwenden. Beide Klassen sind im Paket org.apache.struts.validator enthalten. Durch die Erweiterung von DynaActionForm können Sie eine Validierung basierend auf Basiswertfeldern von XML-Dateien erhalten. Die Validierung basiert auf dem in den Validator eingegebenen Schlüssel. Der Schlüssel ist das Namensattribut aus der Datei struts-config.xml. Es sollte mit dem Namensattribut des Formularelements in der Datei validation.xml übereinstimmen.
Unterstützung mehrerer Anwendungen
In Struts 1.1 können mehrere Unteranwendungen definiert und unterstützt werden. Dies bedeutet, dass Sie Ihre Anwendung in eine Unteranwendung einfügen können, die besser wartbar ist. Sie müssen die Quellcodeverwaltung nicht mehr außerhalb der eindeutigen Datei struts-config.xml erkennen.
Ein weiterer Grund für die Verwendung von Unteranwendungen besteht darin, den Kontrollfluss basierend auf dem Client zu ändern. In einigen Anwendungen gibt es möglicherweise einige gemeinsame Seiten, der Kontrollfluss kann sich jedoch je nach Client, der sich bei der Anwendung anmeldet, ändern. Sie können diese Kontrollfluss-Metadaten in einer Datenbank speichern und eine web.xml-Datei (oder einen Teil davon) zusammen mit einer anderen struts-config.xml-Datei generieren.
Wenn Sie schon einmal für Struts 1.x entwickelt haben, ist Ihnen vielleicht aufgefallen, dass viele Elemente in der web.xml-Datei in die struts-config.xml-Datei von Struts 1.1 verschoben wurden. Dies liegt daran, dass sie jetzt anwendungsspezifisch sind. Mehrere Unteranwendungen werden durch das Präfix identifiziert, das mit dem relativen Kontextteil des Anforderungs-URI beginnt. Wenn kein Anwendungspräfix übereinstimmt, wird die Standardkonfiguration ausgewählt. Die Standardeinstellung hat ein leeres Zeichenfolgenpräfix. Diese Art der Implementierung von Standardeinstellungen ist abwärtskompatibel mit Struts 1.0.x, wo nur eine Anwendung definiert werden darf.
Wenn Sie eine große Anwendung haben, die verschiedene Funktionsmodule enthält, ist es sinnvoller, eine große Anwendung durch zusammen laufende Unteranwendungen zu ersetzen. Die unten gezeigte Datei web.xml zeigt, wie eine Unteranwendung definiert wird.
config
/WEB-INF/struts-config.xml
config/cata log
/WEB- INF/struts-config-catalog.xml
config/sorter
/WEB-INF/struts-config-sorter.xml >
Bei der Verwendung von Unteranwendungen können Sie kontextsensitive Anforderungs-URIs definieren, um anzugeben, welche Unteranwendung verwendet wird. Beispielsweise könnte eine Aktion in einem Formular so aussehen:
bezieht sich auf die Standard-Unteranwendung, oder
bezieht sich auf die Aktionsklasse der Katalog-Unteranwendung. Anwendung. Das müssen Sie eigentlich nicht tun. Sie können /listCds in der Katalogunteranwendung verwenden, wenn Sie dies tun möchten. Die Grundregel lautet: Alle struts-config.xml-Parameter, die in Version 1.0 kontextsensitiv waren, sind jetzt in Version 1.1 präfixspezifisch für Unteranwendungen. Auf diese Weise kann eine einzelne Anwendung ohne Änderung sowohl als Standard-Unteranwendung als auch als designierte Unteranwendung dienen.
Das Obige ist der Inhalt des Lernens von Jakarta Struts 1.1 (2). Weitere verwandte Artikel finden Sie auf der chinesischen PHP-Website (www.php.cn)!
