Eine Webanwendung wird generell über eine Konfigurationsdatei mit dem Namen web.xml konfiguriert.
Diese befindet sich an einer vordefinierten Stelle innerhalb der Webanwendung. Eine Webanwendung besteht dabei aus einem ganz normalen Dateiverzeichnis, der Verzeichnisname entspricht dabei dem Anwendungsnamen und muss innerhalb eines Webservers eindeutig sein.
Das Verzeichnis kann dabei beliebige weitere Dateien und Unterverzeichnisse enthalten, diese bilden den sogenannten statischen Inhalt, also Dateien, die vom Browser direkt angefordert werden können. Üblicherweise liegen hier Bilder, fertige HTML Seiten, JavaScript Dateien, CSS Definitionen etc.
Es gibt in diesem Verzeichnis ein spezielles Unterverzeichnis, das von einem Browser nicht abgefragt werden kann, und zur Konfiguration dient, das Verzeichnis muss den Namen WEB-INF haben.

In diesem Verzeichnis liegt die Konfigurationsdatei web.xml, sowie optional ein Unterverzeichnis lib, in dem eventuell benötigte Java Bibliotheken (jar Dateien) zur Anwendung hinzugefügt werden können.
Möglich ist auch ein optionales Verzeichnis classes, in dem einzelne Java Klassen, die die Anwendung benötigt, hinterlegt werden können.

Die Konfigurationsdatei entspricht dem Java Standard für Webanwendungen. Zur Konfiguration der DWE innerhalb einer Webanwendung sind in einigen Bereichen der Datei Einstellungen möglich.
Dies sind:

• Allgemeine Parameter der Webanwendung für die DWE
• Listener für die DWE
• Definition der DWE Servlets
• Optionale DWE Filter

Allgemeine Informationen über die Struktur und Einstellungsmöglichkeiten innerhalb einer web.xml Konfiguration finden sich in der entsprechenden Fachliteratur. Hier werden nur die Erweiterungen im Rahmen der DWE erläutert.

Hier ein Beispiel einer möglichen Konfiguration:

<!--
Setup the application context.
-->
<!--
Default css and java-script files to import with header.
-->
<context-param>
<description>
Default CSS styles to load. Multiple entries must be separated by a semicolon.
Entries not starting with a / will be prefixed by the context root (web application name).
</description>
<param-name>dle.html.header.default.css</param-name>
<param-value> /dlewebres/dle/css/ui.jqgrid.css;/dlewebres/dle/css/DLE.css</param-value>
</context-param>
<context-param>
<description>
Default java scripts to load. Multiple entries must be separated by a semicolon.
Entries not starting with a / will be prefixed by the context root (web application name).
</description>
<param-name>dle.html.header.default.js</param-name>
<param-value> /dlewebres/dle/js/jquery.min.js;/dlewebres/dle/js/jquery-ui.min.js;/dlewebres/dle/js/jquery.ui.datetimepicker.min.js;/dlewebres/dle/js/jquery.form.js;/dlewebres/dle/js/i18n/grid.locale-{language}.js;/dlewebres/dle/js/jquery.jqGrid.min.js;/dlewebres/dle/js/jquery.quicksearch.js;/dlewebres/dle/js/DLE.js</param-value>
</context-param>
<!--
General setup for the DLE API session pool.
-->
<context-param>
<description>
For a remote API use at.visionflow.dle.dwe.DLERemoteServletApiFactory
For a local API use at.visionflow.dle.dwe.DLELocalServletApiFactory
For a local DLE Server API use at.visionflow.dle.dwe.DLELocalDLEServerApiFactory
</description>
<param-name>dle.sessionPool.factoryClass</param-name>
<param-value>at.visionflow.dle.dwe.DLELocalDLEServerApiFactory</param-value>
</context-param>
<context-param>
<param-name>dle.sessionPool.minPoolSize</param-name>
<param-value>3</param-value>
</context-param>
<context-param>
<param-name>dle.sessionPool.maxPoolSize</param-name>
<param-value>20</param-value>
</context-param>
<context-param>
<param-name>dle.sessionPool.inactivityTimeoutMinutes</param-name>
<param-value>30</param-value>
</context-param>
<!--
Setup parameters for a local DLE API.
-->
<context-param>
<param-name>dle.sessionPool.localfactory.home</param-name>
<param-value>/CVS/DLE</param-value>
</context-param>
<!--
Setup parameters for a remote DLE API.
-->
<context-param>
<param-name>dle.sessionPool.remotefactory.host</param-name>
<param-value>localhost</param-value>
</context-param>
<context-param>
<param-name>dle.sessionPool.remotefactory.port</param-name>
<param-value>7000</param-value>
</context-param>

Zwei Listener, die unter anderem zur Verbindungssteuerung benötigt werden, sind zwingend zu konfigurieren. Sie benötigen keine Parameter, müssen jedoch in der web.xml angegeben sein:

<!--
DLE Application and Servlet listeners.
-->
<listener>
<description>The DLE context listener is used to initialize the DLE components during startup</description>
<listener-class>at.visionflow.dle.dwe.DLEServletContextListener</listener-class>
</listener>
<listener>
<description>The DLE session listener is used to monitor the session lifecycle</description>
<listener-class>at.visionflow.dle.dwe.DLEHTTPSessionListener</listener-class>
</listener>

Über den Kontext Parameter dle.sessionPool.factoryClass wird angegeben, auf welche Art die Verbindung zur DLE hergestellt werden soll:

• at.visionflow.dle.dwe.DLELocalDLEServerApiFactory
• at.visionflow.dle.dwe.DLELocalServletApiFactory
• at.visionflow.dle.dwe.DLERemoteServletApiFactory
• at.visionflow.dle.dwe.DLEAutomaticApiFactory

Die DLELocalDLEServerApiFactory wird benutzt, um die Verbindung aus dem im DLE Server integrierten Jetty Webserver zu erstellen. Diese Verbindungsart benötigt keine weiteren Parameter.

Die DLELocalServletApiFactory kann bei einem Apache Tomcat, sowie bei Tomcat basierenden Webservern (z.B. JBoss) eingesetzt werden.
Sie erweitert den (Tomcat) Webserver so, dass er eine bestehende DLE Installation als Subsystem verwendet. Dazu muss in dem Parameter dle.sessionPool.localfactory.home das Installationsverzeichnis der DLE angegeben werden.

Die DLERemoteServletApiFactory kann verwendet werden, um vom Webserver aus, über die DLE Socket Schnittstelle, einen separaten DLE Server zu verwenden. Dazu müssen in den Parametern dle.sessionPool.remotefactory.host und dle.sessionPool.remotefactory.port der Hostname oder die IP Adresse des Servers sowie der Port des dort konfigurierten Adapters angegeben werden.
Alternativ können diese Parameter auch über eine externe Property Datei oder die System Properties gesetzt werden. Eine externe Property Datei kann dabei über das web.xml Kontext Parameter dle.sessionPool.remotefactory.configfile definiert werden. Ist eine Property Datei definiert, wird zuerst darin nach den Parametern für den Host und den Port gesucht, sind diese dort nicht gesetzt, wird in den Java System Properties nach den Parametern gesucht, sind diese auch dort nicht gesetzt, wird die Einstellung aus der web.xml genommen. Im Dateinamen der Property Datei können Java System Properties als Platzhalter verwendet werden, in der Form ${PropertyName}, also z.B.:

<param-name>
dle.sessionPool.remotefactory.configfile
</param-name>
<param-value>
${SAPS_CONFIG_DIR}/Config.properties
</param-value>

Entsprechend der Einstellung erfolgt dann jeweils die Verbindung zur DLE. Dabei werden die Verbindungen gepoolt, d.h. Es existiert schon eine Reihe von vorgefertigten Verbindungen und diese werden je nach Bedarf von der DWE verwendet. Die Poolgröße (Min/Max) lässt sich auch konfigurieren, sowie ein Timeout nach dem inaktive Verbindungen (z.B. durch beenden des Browsers oder verlassen der Webseite) wieder gelöscht und zur neuen Verwendung freigegeben werden.

Die DLEAutomaticApiFactory entscheidet automatisch, ob eine DLERemoteServletApiFactory oder eine DLELocalDLEServerApiFactory verwendet werden soll. Läuft die Webanwendung innerhalb des integrierten Jetty Webservers, wird die DLELocalDLEServerApifactory verwendet, sonst die DLERemoteServletApiFactory. Diese Einstellung erlaubt es ein und dieselbe web.xml Konfiguration sowohl in einem lokalen Server, z.B. zur Entwicklung, als auch eine Remote Variante, z.B. einem Tomcat Produktivsystem, zu verwenden.

Das CallFolderServlet dient dazu, Webanfragen an einen Webserver an die DLE weiter zu leiten. Eine Servlet Definition gliedert sich dabei immer in zwei Bereiche. Zum einen die reine Definition eines Servlets mit seinen Parametern, zum anderen das sogenannte Servlet Mapping, das URLs zu Servlets zuordnet. Ein Servlet hat mindestens einen Namen, der beliebig gewählt werden kann, jedoch eindeutig innerhalb einer Anwendung sein muss und eine Java Klasse, die für den Aufruf zuständig ist. Beim CallFoldertServlet ist dies die Klasse at.visionflow.dle.dwe.DLECallFolderServlet. Dieses Servlet benötigt zumindest ein weiterer sogenannter Init-Parameter mit Namen dle.folder. Hier wird festgelegt, welcher DLE Ordner (Folder) aufgerufen werden soll.
Eine Minimalkonfiguration eines DLE Aufrufs erfordert daher Beispielhaft folgende Definition:

<servlet>
<servlet-name>Brick</servlet-name> <servlet-class>at.visionflow.dle.dwe.DLECallFolderServlet</servlet-class>
<init-param>
<param-name>dle.folder</param-name>
<param-value>WEB:Tutorial</param-value> </init-param>
</servlet>

Nach der Servlet Definition wird dann über das Servlet Mapping festgelegt, welche URLs zu welchem Servlet geleitet werden.
Die beliebteste und einfachste Methode ist es, einfach alle Aufrufe, die mit „.brick“ enden, an das Servlet weiter zu leiten:

<servlet-mapping>
<servlet-name>Brick</servlet-name>
<url-pattern>*.brick</url-pattern>
</servlet-mapping>

Es können auch mehrere URL Patterns hintereinander angegeben werden, das * darf dabei jedoch nur am Anfang oder am Ende eines Patterns angegeben werden. Alternativ könnte man z.B. alle Anfragen die unterhalb von /secure und /geheim liegen, an ein anderes (vorher definiertes) Servlet weiterleiten, das dann z.B. einen anderen DLE Ordner aufruft:

<servlet-mapping>
<servlet-name>SecureBrick</servlet-name>
<url-pattern>/secure/*</url-pattern>
<url-pattern>/geheim/*</url-pattern>
<url-pattern>/ </url-pattern>
</servlet-mapping>

Das letzte URL Pattern („/“) im obigen Beispiel erlaubt es „Root“ anfragen an die Webanwendung zu beantworten. Ruft man die Web-Anwendung direkt auf, kann man entweder über eine welcome-file Einstellung auf eine statische Seite (z.B. index.html) verzweigen, oder durch ein „/“ (root) Mapping wie oben, zur DLE verzweigen.
Das CallFolderServlet hat weitere optionale Parameter, die als Init-Parameter analog zum dle.folder Parameter angegeben werden können.
Alle Parameter, die mit „dle.“ Anfangen, werden dabei als spezielle Parameter behandelt. Alle weiteren Init-Parameter werden als DLE Felder behandelt. Enthalten sie einen Doppelpunkt, werden sie eins zu eins an die DLE übergeben, ansonsten wird per Default der Wert aus dem Parameter dle.parameter.prefix vorangestellt. Ist dieser Parameter nicht definiert und der Parameter enthält keinen Doppelpunkt, oder fängt mit „dle.“ an, werden sie ignoriert. Auf diese Art kann man innerhalb der DLE Aufrufparameter als DLE Variablen fix vorgeben.

Dies ist ein spezielles Servlet, das für die DLE Kommunikation zwischen Server und Client benötigt wird. Werden in einer DLE Anwendung DLE Dialoge, Nachschlagetabellen oder das Kommando „Script sofort auf Browser ausführen“, bzw. im Parameter „DLE Kommunikation starten“ des <head> Kommandos ein „Ja“ gewählt wurde, ist dieses Servlet zwingend in der web.xml zu definieren.
Auch wenn das Servlet nicht verwendet werden sollte, schlagen wir jedoch vor es grundsätzlich immer zu definieren:

<!--
The client communication handler servlet.
-->
<servlet>
<servlet-name>DLEClientComServlet</servlet-name>
<servlet-class>at.visionflow.dle.dwe.DLEClientCommunicationServlet</servlet-class>
<init-param>
<description>A heartbeat message will be sent to the client every x milliseconds</description>
<param-name>dle.clientCom.HeartbeatMilliseconds</param-name>
<param-value>50000</param-value>
</init-param>
<init-param>
<description>Timeout in milliseconds after which client connections will be dropped</description>
<param-name>dle.clientCom.TimeoutMilliseconds</param-name>
<param-value>180000</param-value>
</init-param>
<init-param>
<description>Default character encoding for the request.</description>
<param-name>dle.request.default.character-encoding</param-name>
<param-value>UTF-8</param-value>
</init-param>
<init-param>
<description>Default character encoding for the response.</description>
<param-name>dle.response.default.character-encoding</param-name>
<param-value>UTF-8</param-value>
</init-param>
</servlet>
<servlet-mapping>
<servlet-name>DLEClientComServlet</servlet-name>
<url-pattern>/DLEClientCom</url-pattern>
</servlet-mapping>

Die Parameter haben folgende Bedeutung:

Per Default ist das Servlet auf die URL /DLEClientCom gemappt. Dieses Mapping kann auch geändert werden, jedoch ist dazu auch die DLE.JS Variable DLE.dleClientComName auf dem Browser zu ändern. Das kann durch JavaScript nach der Initialisierung der DLE erfolgen.

Die Klasse at.visionflow.dle.dwe.DLESecurityFilter kann als Servlet Filter in der web.xml definiert werden:

<filter>
<filter-name>DLESecurity</filter-name> <filter-class>at.visionflow.dle.dwe.DLESecurityFilter</filter-class>
<init-param>
<description>Forward the request to this page, if the user is not logged in</description>
<param-name>dle.loginPage</param-name>
<param-value>/login.brick</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>DLESecurity</filter-name> <url-pattern>*.sbrick</url-pattern>
<url-pattern>/secret/*</url-pattern>
</filter-mapping>

Das Vorgehen ist dabei das gleiche wie bei der Definition eines Servlets. Zuerst wird der Filter an sich definiert, mit einem eindeutigen Namen, danach wird ein Mapping definiert, das festlegt, auf welche URLs der Filter greift.
Der DLESecurityFilter prüft bei einer eingehenden Anfrage auf diesen URLs, ob der Benutzer angemeldet ist (Siehe Feld WEB:UserIsLoggedIn auf Seite 25).
Ist der Benutzer angemeldet, wird die Anfrage normal weiter bearbeitet.
Ist der Benutzer nicht angemeldet, wird die Anfrage an eine andere URL weitergeleitet, z.B. einer Fehlermeldungsseite oder eine Login-Seite.
Die URL, an die die Anfrage weitergeleitet werden soll, wird mit dem Filter Parameter dle.login konfiguriert.
Der weitergeleiteten Anfrage wird zudem noch die ursprünglich angeforderte URL als Anfrageattribut (Siehe Seite 29 und Kommando HTTP Anfrageattribut lesen auf Seite 34) mit dem Namen dle.targetLink.

Mitgeliefert wird eine statische Web-Anwendung mit Namen dlewebres.
Diese liegt unter packages/WEB/web-apps/dlewebres.

Sie enthält nur statische JavaScript und CSS Ressourcen, die für die meisten DLE Kommandos benötigt werden.
Die Anwendung muss nicht konfiguriert werden, sollte aber auf jeden Webserver mit deployed werden, auf dem eine DLE Anwendung läuft.
Die DLE Webanwendungen sollten ihre statischen JavaScript und CSS Ressourcen direkt von dort laden, in der web.xml sollten diese in den Parametern für dle.html.header.default.css und dle.html.header.default.css eingetragen werden. Also als absoluter Pfad, z.B. /dlewebres/dle/DLE.js.

Um das Suchdatum für die Bricksuche auch über das Web dynamisch angeben zu können, wurde mit der Version 1.6.6 die Basisvariable BASE:SearchDate (BASE:Felder Suchdatum) eingeführt. Über diese variable kann als GET oder POST Parameter das gewünschte Suchdatum übergeben werden.

Die Installation einer Webanwendung, Deployment genannt, erfolgt je nach Webserver Setup leicht unterschiedlich.
Für das Deployment auf einen speziellen Webserver ist die Dokumentation des Webservers zu befolgen. Grundsätzlich bedeutet ein Deployment nichts weiter, als das Anwendungsverzeichnis (siehe Seite 11, Konfiguration einer Webanwendung), in ein definiertes Verzeichnis des Webservers zu kopieren.
Webserver wie Tomcat und der integrierte Webserver im DLE Server erlauben dabei das Deployment einer sogenannten Root Anwendung.
Dabei hat das Anwendungsverzeichnis den speziellen Namen root, bzw. das die WAR Datei den Namen root.war und wird damit speziell behandelt.
Die Ressourcen der Root Anwendung sind nicht über den Anwendungsnamen erreichbar, sondern liegen direkt unter dem Startpfad des Webservers. Also z.B. anstatt unter localhost/my_app/Index.brick, wenn die Anwendung my_app heißt, dann direkt unter localhost/Index.brick.

Dies ist die einfachste Möglichkeit, eine Webanwendung den Anwendern zugänglich zu machen.
Der DLE Server enthält einen optionalen integrierten Webserver, der für Webanwendungen verwendet werden kann.
Beim Start des DLE Servers überprüft der Webserver dabei alle Paketverzeichnisse. Enthalten diese ein Unterverzeichnis namens web-apps, so werden alle Webanwendungen, die darunter liegen, gestartet.
Zur Erstellung einer Webanwendung ist also einfach ein Verzeichnis mit dem Anwendungsnamen unter dem Unterverzeichnis web-apps im Paketverzeichnis des gewünschten Pakets anzulegen. Darunter wiederum ist das Konfigurationsverzeichnis mit der web.xml Konfiguration, wie weiter oben beschrieben, anzulegen. Danach steht die Webanwendung zur Verfügung.

Das Anwendungsverzeichnis wird in diesem Fall in das sogenannte Deployment Verzeichnis des Webservers kopiert. Optional kann es auch als ZIP oder JAR Datei mit der speziellen Endung „.war“ (anstatt .zip oder .jar) dorthin kopiert werden. Einige Webserver erlauben das „Deployment“ von Webanwendungen auch über eine Web Administrationsanwendung. Diese benötigen normalerweise solch eine .war Datei als Dateiupload.

Da, im Gegensatz zum DLE Server, ein Webserver die DLE Klassen und Funktionen nicht kennt, sind einige zusätzliche Dateien mitzuliefern.
Unterhalb des Konfigurationsordners einer Webanwendung (WEB-INF) ist ein Verzeichnis Namens lib anzulegen. Hier hinein müssen einige DLE relevante JAR Dateien vor dem Deployment kopiert werden. Es sind:

• dle_web.jar aus dem DLE Verzeichnis packages/WEB/lib/
• jdom.jar aus dem DLE Verzeichnis lib/
• dleClient.jar aus dem DLE Verzeichnis tools/
• commons-fileupload.jar aus dem DLE Verzeichnis packages/WEB/lib/

Zwei Funktionalitäten innerhalb der DWE verwenden aktiv eine Server-Client Kommunikation. Dies sind zum einen die normalen DLE Dialoge im Brick, sowie das Kommando „Script sofort auf Browser ausführen“.
Dazu muss die Anwendung die DLE Kommunikation initialisiert und gestartet haben. Normalerweise geschieht dies durch Parameter im <head> Kommando.

DLE Dialoge, über das DLE Dialog Kommando, sowie Meldungen und Ja/Nein Abfragen können ohne Einschränkungen und Änderungen an den Kommandos auch im Webumfeld eingesetzt werden.
Durch die DWE werden Dialoge und Meldungen in HTML Dialoge umgesetzt („gerendert“) und vom Brick über die Kommunikationsschnittstelle an den Browser gesandt, der diese anzeigt und die Webseite solange blockiert, bis der Dialog abgeschlossen wurde.
Der Brick wartet an der Dialogstelle solange mit der weiteren Ausführung, bis der Dialog bestätigt wurde.
Browserseitig wurde zudem eine Validierung der Eingaben eingeführt. Pflichtfelder, numerische und Datumseingaben werden auf Korrektheit geprüft und der Dialog nur dann bestätigt, wenn diese korrekt erfolgt sind.
Zur Darstellung der Dialoge verwendet die DLE die Defaulteinstellungen der HTML Seite für Farben, Schriftarten, Schriftgrößen etc.
Natürlich können diese mit den normalen Dialogparametern auch individuell angepasst werden. Auch die Positionierung der Elemente erfolgt in gewohnter DLE Art und Weise.