Für den eiligen Berater

... folgt hier eine Kurzanleitung zum Erstellen von Web-Anwendungen mit dem MVC-Framework. Folgende Vorgehensweise ist zu empfehlen:

Zwei Abnahmetermine mit dem Auftraggeber ausmachen

Machen Sie zwei Abnahmetermine statt einem mit dem Auftraggeber aus:

Gruppieren Sie die Anwendungsteile nach Aufgabenbereichen

Klären Sie, in welche Teile die gesamte Anwendung sinnvollerweise zerfällt. Oft gibt es eine zentrale Dach-Anwendung, in die verschiedene eigenständige Anwendungen eingebettet sind. Dann empfiehlt es sich, für die Dach-Anwendung und für jede der eigenständigen Anwendungen jeweils eine eigene BSP-Applikation zu erstellen.

Kopieren Sie zmvc_template

Erstellen Sie eine neue BSP-Anwendung nicht von der Pike auf, sondern kopieren Sie die Vorlageapplikation zmvc_template. Diese enthält Anwendungsteile, die fast immer benötigt werden:

Setzen Sie den Parameter Z_MVC_DEVELOPER auf X.

Dann bekommen Sie beim Entwickeln ein Fehlerprotokoll angezeigt, wenn die Flow Logic nicht korrekt ausgewertet werden kann. Ausserdem wird dann die beim Entwickeln eher störende Pufferung nicht ausgeführt: Die Flow Logic wird bei jedem Request neu ausgewertet.

Passen Sie die Flow Logic an

Auf jeden Fall müssen Sie den Applikationsnamen im <application> Element von zmvc_template auf den Namen Ihrer neuen Anwendung umändern.

Ist dies geschehen, sollte sich die Anwendung bereits starten lassen.

Probieren Sie es, indem Sie den Controller main.do im Einzeltest aufrufen!

Häufig ist eine Anwendung lediglich eine Folge von Bildern, die vom Benutzer sequentiell oder mit einer Navigationsleiste erreicht werden. Die in allen Bildern gleichbleibenden Teile behalten Sie im View main.htm, die wechselnden Teile kommen in einzelne Views view1.htm, view2.htm etc., die Sie jeweils einem Panelwert panel1, panel2 etc. zuordnen.

Die config.xml könnte dann zum Beispiel so aussehen:

<?xml version="1.0"?>
<application name="zbeispiel"
             stateful="false">
  <controller id="main"
              name="main.do"
              class="zcl_controller">
    <panel name="panel1" default="true">
      <component name="content"
                 view="panel1.htm"/>         
    </panel>
    <panel name="panel2">
      <component name="content"
                 view="panel2.htm"/>         
    ...
    <component name="navi"
               view="navigation.htm"/> 
    <callsView name="main.htm"/>
  </controller>
Verwenden Sie in Ihrer wirklichen Anwendung sprechende Namen für die Panels und Views.

Der View navigation.htm könnte den allen Bildern gemeinsamen Navigationsbereich enthalten, dessen HTML-Code aus Gründen der Klarheit in einen eigenen View ausgelagert wird und im Hauptview unter dem Komponentennamen navi ansprechbar ist: Definieren Sie in diesem Beispiel zwei Seitenattribute navi und content vom Typ ref to if_bsp_page in der Hauptsicht main.htm.

Dann können Sie die Komponenten mit der Anweisung <%call_view( ... )%> an den vorgesehenen Stellen einbinden. Das Framework (in diesem Fall die in zcl_controller programmierte Logik) liefert dem View main.htm in den Attributen content und navi die je nach Anwendungszustand korrekten View-Instanzen.

Entwerfen Sie die Views, Stylesheets und sonstigen Ressourcen

Nun sind Sie als Web-Designer gefragt. Setzen Sie die Anforderungen des Auftraggebers in HTML- und CSS-Code um. Wenn Sie wollen, können Sie hierzu externe Tools verwenden. (Ich persönlich ziehe die Arbeit mit einem reinen Texteditor vor, etwa UltraEdit oder TextPad.) Der Code wird zunächst statisch sein. Es ist nicht schlimm, in der Phase "Erstellung des User Interface" Felder mit festen Werten zu belegen. Besser ist es allerdings, die Dummywerte bereits im Code des Models zu hinterlegen und in den Views schon die geplanten Datenbindungsausdrücke zu verwenden. Egal wie Sie hier vorgehen - achten Sie in dieser Phase vor allem darauf, dass die Navigation überall korrekt funktioniert.

Verwenden Sie eine eigene Tag Library für übergreifende visuelle Elemente

Mit dem Download erhalten Sie eine Tag Library Z, die das Look And Feel des SAP Retail Store hat. Dies wird wohl nur in seltenen Fällen das von Ihrem Auftraggeber gewünschte Layout sein. Es ist aber einfach, wiederkehrende graphische Elemente in einer eigenen BSP-Extension zu kapseln. Lesen Sie hierzu Abschnitt 11.2 des BSP-Praxisbuchs. Sie können sich bei der Implementierung auch von den bestehenden Extensionen wie HTMLB und Z über die technischen Möglichkeiten eines BSP-Elementbehandlers inspirieren lassen.

Diesen Schritt - aus den Seiten wiederkehrendes HTML herauszuziehen und in eine BSP-Extension zu verlagern - können Sie, wenn der Abnahmetermin drückt, auch später noch nachholen - besonders dann, wenn Sie Ihre Anwendungen automatisiert testen. Auch dies läuft unter dem Thema Refactoring.

Fügen Sie inkrementell die Geschäftslogik hinzu

Wenn User Interface und Navigation aus Sicht des Auftraggebers OK sind, können Sie damit beginnen, die Geschäftslogik hinzuzufügen. Orientieren Sie sich dabei am Kapitel 8 des BSP-Praxisbuchs, das ganz einem praktischen Beispiel gewidmet ist (dem QM-Tool):

Sehen Sie stets die Möglichkeit von Änderungen der Anforderungen vor.

Meisseln Sie Ihre Entwurfsentscheidungen nicht in Stein. Machen Sie sie nicht von konkreten Anforderungen abhängig, die sich möglicherweise ändern können. Halten Sie den Entwurf so flexibel, dass er jederzeit um Änderungen ergänzt werden kann. Auch radikale!

Wenn Sie diesen Weg beschreiten...

... können Sie optimistich sein, zeitgerecht zum Ziel zu kommen! Auch nach dem GoLive können Sie mit wenig Aufwand noch Nachbesserungen und Änderungen ausführen.

Zurück