In Portal-Anwendungen ist es möglich, mehrere Portlets auf einer Webseite anzuzeigen. Da insbesondere auch das gleiche Portlet mehrfach auf der Webseite angezeigt werden kann, muss die Portal-Anwendung die Eindeutigkeit der HTML-IDs sicherstellen. Zu diesem Zweck wird jeder Portlet-Instanz in der Regel eine dynamische ID zugeordnet, die als Präfix für die HTML-IDs verwendet wird. Die Vergabe der Portlet-ID kann während des Deployments oder während des Starts des Application-Servers erfolgen. Insbesondere ist diese Portlet-ID zum Zeitpunkt der Testerstellung nicht verfügbar. Wie kann man in diesem Umfeld GUI-Tests programmieren?

Checkerberry web bietet den großen Vorteil des Modellansatzes, über den die erforderliche Implementierung realisiert werden kann. Die Lösung ist dabei von der konkreten Anwendung und Portal-Implementierung abhängig. Dennoch lässt sich ein allgemeiner Lösungsweg beschreiben.

Die wesentliche Aufgabe bei dem Test von Portal-Anwendung besteht darin, die Zuordnung zwischen Portlet und Portlet-ID herzustellen. Zu diesem Zweck bietet checkerberry web die abstrakte Klasse AbstractRemoteControlPortlet. Für jedes Portlet der Anwendung wird eine eigene Portlet-Klasse implementiert z.B. LoginPortlet. In dieser Klasse implementiert der Entwickler Getter-Methode für alle Webseiten, die zu diesem Portlet gehören z.B. public LoginPage getLoginPage(). Die abstrakte Portlet-Klasse verfügt über das Property portletId. Dieses Property kann über die enthaltenen Page-Modellklassen an die Komponenten weitergereicht werden.

Das folgende Beispiel zeigt eine Implementierung der LoginPage im Portal-Umfeld. Im Gegensatz zu dem vorherigen Beispiel enthält die LoginPage-Klasse nun eine Referenz auf das Portlet, in dem die Seite angezeigt wird. Über die Portlet-ID kann dann die HTML-ID der enthaltenen Komponenten dynamisch erzeugt werden.

public class LoginPage extends AbstractRemoteControlPage {

  private AbstractRemoteControlPortlet portlet;

  // Konstruktor mit Contextprovider und Portlet aufrufen
  public LoginPage(ContextProvider contextProvider, AbstractRemoteControlPortlet portlet) {
      super(contextProvider);
      this.portlet = portlet;
  }

  public RemoteControlComponent getUserTextField() {
    // Portlet Präfix bei der HTML-ID berücksichtigen.
    return createComponentProxy(portlet.getPortletId() + ":userId");
  }
}

Da das LoginPage-Modell über das Portlet erzeugt wird, kann die Referenz auf das Portlet leicht übergeben werden. Das folgende Beispiel zeigt eine mögliche Implementierung.

public class LoginPortlet extends AbstractRemoteControlPortlet {

  // Konstruktor mit Fernsteuerung und ContextProvider aufrufen
  public LoginPortlet(ContextProvider contextProvider) {
    super(contextProvider);
  }

  public LoginPage getLoginPage() {
    // LoginPage mit Referenz auf dieses Portlet aufrufen. (Das
    // Portlet ist auch ein ContextProvider...)
    return new LoginPage(this);
  }
}

Das Portlet-Modell wird mit dem aktuellen ContextProvider erzeugt. Über Getter-Methoden werden die Modelle der Webseiten zur Verfügung gestellt, die innerhalb des Portlets verwendet werden. Bei der Erzeugung dieser Modelle wird die Referenz auf das entsprechende Portlet einfach übergeben.

Das vorgestellte Verfahren bietet eine gute Möglichkeit, Modelle in Portal-Umgebungen zu definieren. Die entscheidende Frage ist bisher jedoch unbeantwortet geblieben: Wie kann die Portlet-ID für ein Portlet ermittelt werden?

Eine Möglichkeit für die Ermittlung der Zuordnung von Portlet und Portlet-ID besteht in der Erweiterung der HTML-Datei. Über ein zusätzliches oder bestehendes HTML-Tag kann die Information in die Webseite eingebunden werden. Es ist z.B. möglich, ein DIV-Element um jedes Portlet zu definieren, das einen Portlet-Namen und die Portlet-ID in der HTML-ID enthält z.B. <DIV ID=“PORTLET:NAME=Login;ID=XYZ4711“>. Der vollständige Inhalt der HTML-Seite kann über die Methode RemoteControl.getHtmlSource() ermittelt werden, sodass die Zuordnung ausgelesen und interpretiert werden kann.

Es ist abhängig von der Portal-Anwendung, wann die Zuordnung von Portlet und Portlet-ID ausgelesen und verarbeitet wird. Aus Performance-Gründen kann es sinnvoll sein, die HTML-Seite einmal einzulesen und in die ermittelten Zuordnungen in der Klasse WebContext zu speichern. In anderen Portal-Anwendungen kann es sinnvoller sein, die Zuordnung direkt bei der Erzeugung des Portal-Modells vorzunehmen.