GlossarWiki - Benutzerbeiträge [de-formal]

HTML5-Tutorium: Canvas: MiniPong 04

2016-12-02T10:31:15Z

Sautter:

{{HTML5-Tutorium:Canvas:MiniPong:Menü}}
'''Musterlösung''': <code>[https://glossar.hs-augsburg.de/beispiel/tutorium/es5/minipong/WK_MiniPong04/web/index.html index.html]</code>
([https://glossar.hs-augsburg.de/beispiel/tutorium/es5/minipong/WK_MiniPong04/ WK_MiniPong04 (SVN)])

'''Leeres Projekt''': <code>[https://glossar.hs-augsburg.de/beispiel/tutorium/es5/minipong/WK_MiniPong04_empty/web/index.html index.html]</code>
([https://glossar.hs-augsburg.de/beispiel/tutorium/es5/minipong/WK_MiniPong04/ WK_MiniPong04_empty (SVN)])

==Ziel: Das fertige Spiel „MiniPong“==
Im vierten Teil des Tutoriums wird eine funktionsfähige Version von MiniPong erstellt.

===Use Cases===
[[Datei:MiniPong04 UseCases.png|ohne|882px|Use Cases der Tutoriums-Anwendung <code>MiniPong</code>]]
Ein Spieler kann das Spiel starten (Startknopf) und vorzeitig
beenden (Stopp-Knopf). Nach Spielstart kann der Spieler den Schläger
am unteren Rand des Spielfeldes mit Hilfe der Richtungstasten des
Keyboards nach links und rechts bewegen.

Nachdem das Spiel gestartet wurde, bewegt sich
der Ball geradlinig im Spielfeld, wobei die Startrichtung zufällig
gewählt wird. Kollisionen mit der linken, oberen oder
rechten Wand haben eine Richtungsänderung des Balls
zur Folge (Einfallswinkel = Ausfallwinkel).
Eine Kollision mit der unteren Wand beendet das Spiel.

Ziel des Spiels sind möglichst viele Kollision des Balls mit
dem Schläger. Eine derartige Kollision hat eine Richtungsänderung
sowie einen Punktgewinn zur Folge. Der aktuelle Punktestand (Score)
wird der Benutzer jederzeit angezeigt.

Wird der Schläger im Moment der Kollision bewegt, so wird der Ball abhängig von der
Bewegungsrichtung und Geschwindigkeit des Schlägers abgelenkt (Simulation von Reibung).

===Klassenmodell===
[[Datei:MiniPong04 ClassModel Overview.png|gerahmt|rechts|Klassendiagramm]]

Eine genauere Analyse der Use Cases zeigt, welche Module benötigt werden. Die verschiedenen Module sind verschieden eingefärbt:

* grau: Initialisierung der Anwendung
* blau: Model der Anwendung
* orange: Controller zur Behandlung der Benutzeraktionen (mit Ausnahme von Formularelementen, die in der View enthalten sind)
* flieder: Anwendungslogik
* grün: Anwendungsview
* gelb: Kollisionserkennung und -behandlung

Die Kollisionserkennung und -behandlung erhält eine eigene Farbe, da sie eine Mischung aus
Model und Controller ist. Einerseits verändert sie die Bewegungseigenschaften beweglicher Objekte (Ball und Schläger).
Das heißt, sie ist wesentlicher Bestandteil des Models. Andererseits informiert sie die Anwendung über Aktionen
des Balls, damit diese entsprechend reagieren kann. Dies ist eine typische Controllertätigkeit.

Das Modul „<code>init</code>“ hat die Aufgabe das Spiel zu initialisieren. Es definiert eine [[Prozedur]]
„<code>init</code>“, die zunächst die wesentlichen Objekte erstellt und dann das Spiel startet.
Im Klassendiagramm sind rote Pfeile zu den Modulen eingezeichnet, die das Init-Modul benötigt.
Das sind die beiden Funktionsmodule „<code>logic/minipong</code>“ und „<code>control/keyboard</code>“
sowie diverse Model- und View-Klassen. Für jede dieser Klassen – mit Ausnahme der Klasse „<code>ModelStage</code>“ –
erzeugt <code>init</code> ein oder im Falle der Text-Klassen sogar jeweils zwei Objekte. Als Stage-Objekt kommt
– wie im [[HTML5-Tutorium: Canvas: MiniPong 03|dritten Teil des Tutoriums]] – das in der HTML-Datei enthaltene
Canvas-Element zum Einsatz.

Die View-Objekte sind ausschließlich der Prozedur „<code>init</code>“ bekannt. Diese Objekte visualisieren
die Model-Objekte, {{dh}} den aktuellen Zustand des Spiels. Da sich der Zustand des Spiel häufig ändert,
erstellt <code>init</code> eine View-Loop, deren Aufgabe es ist, die Visualisierung möglichst häufig,
am Besten 60 mal pro Sekunde zu erneuern. Dazu ruft die View-Loop, sobald sie einmal gestartet wurde,
regelmäßig die Zeichenmethode „<code>draw</code>“ der einzelnen View-Objekte auf.

[[Datei:MiniPong04 ClassModel ViewLoop.png|gerahmt|rechts|Klassendiagramm: Detailansicht der View-Loop]]
Die View umfasst sechs Elemente:
* einen Button (Start, Stopp)
* einen Ball
* einen Schläger
* zwei Textfelder (Score und allgemeine Informationen)
Die View-Loop muss diese sechs Objekte selbstverständlich kennen, damit sie sie darstellen kann.
Die entsprechenden Beziehungspfeile (blau markiert) werden allerdings nur der nebenstehenden Detailansicht des Klassendiagramms,
aber nicht im Übersichtsdiagramm angezeigt (da das Übersichtsdiagramm anderenfalls etwas unübersichtlich werden würde).
Die Init-Prozedur erzeugt diese View-Objekte sowie die zugehörigen Model-Objekte, ordnet
den View-Objekten die entsprechenden Model-Objekte zu und übergibt dann ein Array mit allen View-Objekten der View-Loop.
Sobald diese gestartet wird, aktualisiert sie regelmäßig die grafische Darstellung dieser Objekte im HTML-Dokument.

Die Init-Prozedur lädt ein weiteres Modul: „<code>control/keyboard</code>“. Diese fängt alle Tastaturereignisse ab.
Sobald auf der Tastatur eine entsprechende Taste gedrückt wird, ruft sie sie Methode „<code>start</code>“ des Schlägers
({{dh}} eines Objektes der Klasse „<code>ModelPaddle</code>“) auf und setzt ihn in Bewegung.
Welcher Taste welche Bewegungsrichtung zugeordnet ist, wird in der Init-Datei „<code>init.json</code>“ festgelegt.

Danach wird das eigentlich Spiel gestartet. Die Spiellogik wird in der Prozedur „<code>minipong</code>“ implementiert.
Diese Prozedur muss die Model-Objekte des Spiels kennen, da sie deren Werte liest und in bestimmten Situationen verändert.
Jede Änderung einen Model-Objekts, dem ein View-Objekt zugeordnet ist, wird fast sofort (genau gesagt, bei der nächsten Ausführung
der View-Loop) visualisiert. Da dies automatisch geschieht, muss die Prozedur „<code>minipong</code>“ nichts weiter machen,
als beispielsweise den Text innerhalb eines Text-Objekts der Klasse „<code>ModelText</code>“ oder die Beschriftung des Buttons
innerhalb des Objekts der Klasse „<code>ModelButton</code>“ zu ändern. Sobald dies geschehen ist, wird die Änderung im HTML-Dokument
automatisch übernommen.

Die Spiellogik hat zwei wichtige Aufgaben:
# Simulation der Ball/Schläger-Physik
# Reaktion auf Ereignisse wie Aktivierung des Start-Buttons (Spielstart), Kollision des Schlägers mit dem Ball (Punktgewinn), Verlust des Balles am unteren Bühnenrand (Spielende) etc.

[[Datei:MiniPong04 ClassModel ModelLoop.png|gerahmt|rechts|Klassendiagramm: Detailansicht der Model-Loop]]
Für die erste Aufgabe verwendet sie eine Model-Loop, die alle beweglichen Objekte, {{dh}} alle Model-Objekte, die über die Methode
„<code>move</code>“ verfügen, möglichst oft pro Sekunde mittels dieser Methode an eine neue Position verschiebt.
Das nebenstehende Diagramm zeigt abermals eine Detailansicht des Klassendiagramm, in dem alle für die ModelLoop notwendigen
Beziehungen eingetragen wurde. Auch hier gilt: Im Übersichtsdiagramm wurden die Beziehungspfeile, die im nebenstehenden Diagramm blau markiert wurden,
aus Gründen der Übersichtlichkeit nicht eingetragen.

Die Model-Loop wird nicht von der Init-Prozedur, sondern von der Prozedur „<code>minipong</code>“ erzeugt.
Die Init-Prozedur benötigt dieses Objekt nicht. Die MiniPong-Prozedur benötigt es dagegen nicht nur, sondern muss es auch
gemäß ihren Bedürfnissen initialisieren: Der ModelLoop muss eine spezielle Kollisionsfunktion übergeben werden.

Die zweite Aufgabe „Reaktion auf Ereignisse“ zerfällt in zwei Aufgaben.
# Reaktion auf Aktionen des Benutzers.
# Reaktion auf Aktionen des Balls.

In diesem Spiel gibt es nur eine Benutzeraktion, auf die <code>minipong</code> direkt reagieren muss: „Klick auf den Start-Stopp-Button“ .
Die zweite Aktion „Bewegung des Schlägers“ wird vom Keyboard-Controller direkt an den Schläger weitergeleitet.
Für die Aktion „Button-Klick“ muss <code>minipong</code> dem Button in jedem der beiden Spielzustände „Spiel gestoppt“ und „Spiel gestartet“
eine geeignete Callback-Funktion zuweisen, die die jeweils passende Aktion ausführt. Im Fall „Spiel gestoppt“ muss der Button-Klick das
Spiel starten und im Fall „Spiel gestartet“ muss er das Spiel beenden.

Der Ball kann zwei weitere Aktionen ausführen. Er kann mit dem Schläger kollidieren oder das Spielfeld verlassen. Beide Aktionen werden von
der Kollisionsbehandlung erkannt. Jedes mal, wenn eine wenn der Ball eine dieser beiden Aktionen durchführt
muss die Prozedur „<code>minipong</code>“ darüber informiert werden, damit sie entsprechend reagieren kann.
Hierzu definiert sie mit Hilfe der drei Hilfs-Prozeduren „<code>collisionBallPaddle</code>“, „<code>collisionBallPaddle</code>“
und „<code>collisionStagePaddle</code>“ eine geeignete Kollissionsprozedur, die sie der Model-Loop zur Kollisionserkennung und
-behandlung übergibt.

==Neues Projekt anlegen==

Legen Sie ein neues Projekt mit dem Namen „<code>MiniPong04</code>“ an.

Erstellen Sie folgende Ordner:

* <code>web</code>
* <code>web/css</code>
* <code>web/json</code>
* <code>web/js</code>
* <code>web/js/lib</code>
* <code>web/js/lib/require</code>
* <code>web/js/app</code>
* <code>web/js/app/collision</code>
* <code>web/js/app/control</code>
* <code>web/js/app/logic</code>
* <code>web/js/app/model</code>
* <code>web/js/app/view</code>

Kopieren Sie folgende Dateien des Projektes [https://glossar.hs-augsburg.de/beispiel/tutorium/es5/minipong/WK_MiniPong03/ MiniPong03]
in das neue Projekt:

* <code>web/index.html</code> (Ersetzen Sie im Titel „<code>MiniPong03</code>“ durch „<code>MiniPong04</code>“ und ersetzen Sie im Copyright-Kommentar meinen Namen durch Ihren Namen.)
* <code>web/css/main.css</code>
* <code>web/js/lib/require/json.js</code>
* <code>web/js/lib/require/require.js</code>
* <code>web/js/lib/require/text.js</code>

Erstellen Sie die Datei „<code>web/js/main.js</code>“ und fügen Sie folgenden Code ein:
<source lang="javascript">
requirejs.config
({
baseUrl: 'js', // By default load any modules from directory js
paths :
{
app: 'app',

model: 'app/model',
view: 'app/view',
control: 'app/control',
logic: 'app/logic',
collision: 'app/collision',

loadjson: 'lib/require/json',
text: 'lib/require/text',
json: '../json'
}
});

requirejs
( ['loadjson!json/init.json', 'app/init'],
function(initJSON, init)
{
//init(window, initJSON);
}
);
</source>

Für jedes Modulpaket wurden ein Ordner angelegt und eine Kurzbezeichnung des Modulpfades festgelegt:

{| class="datatable-rt"
! Farbe !! Ordner !! Modulpfad !! Modulzweck
|-
| data-title="Farbe" | grau
| data-title="Ordner" | <code>js/app</code>
| data-title="Modulpfad" | <code>app</code>
| data-title="Modulzweck" | Initialisierung der Anwendung
|-
| data-title="Farbe" | blau
| data-title="Ordner" | <code>web/js/app/model</code>
| data-title="Modulpfad" | <code>model</code>
| data-title="Modulzweck" | Model der Anwendung
|-
| data-title="Farbe" | grün
| data-title="Ordner" | <code>web/js/app/view</code>
| data-title="Modulpfad" | <code>view</code>
| data-title="Modulzweck" | Anwendungsview
|-
| data-title="Farbe" | orange
| data-title="Ordner" | <code>web/js/app/controller</code>
| data-title="Modulpfad" | <code>controller</code>
| data-title="Modulzweck" | Controller zur Behandlung der Benutzeraktionen
|-
| data-title="Farbe" | flieder
| data-title="Ordner" | <code>web/js/app/logic</code>
| data-title="Modulpfad" | <code>logic</code>
| data-title="Modulzweck" | Anwendungslogik
|-
| data-title="Farbe" | gelb
| data-title="Ordner" | <code>web/js/app/collision</code>
| data-title="Modulpfad" | <code>collision</code>
| data-title="Modulzweck" | Kollisionserkennung und -behandlung
|}

Erstellen Sie für jedes Modul, das im Klassendiagramm aufgeführt ist (mit Ausnahme von <code>ModelStage</code>), eine '''leere''' Datei
in der dieses Modul implementiert wird. Achten Sie darauf, dass die Farbmarkierung der Module mit den Farbmarkierungen
der Modulordner übereinstimmt:

'''<code>web/js/app</code>'''
* <code>init.js</code>

'''<code>web/js/app/model</code>'''
* <code>button.js</code>
* <code>ball.js</code>
* <code>paddle.js</code>
* <code>text.js</code>
* <code>loop.js</code>

'''<code>web/js/app/view</code>'''
* <code>button.js</code>
* <code>ball.js</code>
* <code>paddle.js</code>
* <code>text.js</code>
* <code>loop.js</code>

'''<code>web/js/app/control</code>'''
* <code>keyboard.js</code>

'''<code>web/js/app/logic</code>'''
* <code>minipong.js</code>

'''<code>web/js/app/collision</code>'''
* <code>ball_paddle.js</code>
* <code>stage_ball.js</code>
* <code>stage_paddle.js</code>

Fügen Sie in jede Datei ein RequireJS-Kommando ein, das dafür sorgt, dass die benötigten Module geladen und die darin definierten
Funktionen ({{dh}} Prozeduren bzw. Konstruktorfunktionen) dem Modul zur Verfügung gestellt werden. Welche Module
ein Modul benötigt, erkennt man an den roten Pfeilen im Klassendiagramm.

Von den meisten Module geht kein roter Pfeil aus. In diese können Sie jeweils folgenden Code einfügen:

<source lang ="javascript">
define
( [],
function()
{ "use strict";

return null;
}
);
</source>

Von <code>minipong</code> gehen vier rote Pfeile aus. Das heißt, in die Datei „<code>minipong.js</code>“
müssen sie folgende RequireJS-Kommando einfügen:

<source lang ="javascript">
define
(['collision/ball_paddle', 'collision/stage_ball', 'collision/stage_paddle',
'model/loop'
],
function(collisionBallPaddle, collisionStageBall, collisionStagePaddle,
ModelLoop
)
{ "use strict";

return null;
}
);
</source>

Die Reihenfolge, in der Sie die benötigten Module laden, ist unwichtig.
Wichtig ist nur, dass die Reihenfolge der Kurzbezeichnungen der Modulpfade mit
der Reihenfolge der Parameter in der Callback-Funktion übereinstimmt.

Das Init-Modul „<code>app/init</code>“ benötigt sehr viele andere Module, um seine Aufgabe zu erledigen.
Entsprechend lang ist die Modulliste:

<source lang ="javascript">
define
( ['model/button', 'view/button',
'model/ball', 'view/ball',
'model/paddle', 'view/paddle',
'model/text', 'view/text',
'view/loop',
'control/keyboard',
'logic/minipong'
],
function(ModelButton, ViewButton,
ModelBall, ViewBall,
ModelPaddle, ViewPaddle,
ModelText, ViewText,
ViewLoop,
controlKeyboard,
minipong
)
{ "use strict";

return null;
}
);
</source>

Jetzt fehlt noch die Datei „<code>web/json/init.json</code>“, die schon ziemliche Ausmaße angenommen hat,
weil sie für (fast) jedes Modul im Diagramm geeignete Initialwerte enthält:
<source lang="javascript">
{
"canvas":
{
"element": "canvas",
"width": 400,
"height": 300
},

"game":
{
"fps": 120,

"welcome": "Willkommen bei MiniPong",
"ballLost": "Das Spiel ist vorbei :-(",

"startGame": "Spiel starten",
"stopGame": "Spiel beenden"
},

"model":
{
"buttonStartStop":
{},

"ball":
{
"r": 10,
"pos": { "x": 195 , "y": 10 },
"vel": { "x": { "min": 50, "max": 200 },
"y": { "min": 150, "max": 200 }
}
},

"paddle":
{
"width": 50,
"height": 8,
"pos": {"x": 175, "y": 287},
"vel": {"x": 100, "y": 0},
"acc": {"x": 500, "y": 0},
"friction": 0.3
},

"info":
{
"pos": {"x": 10, "y": 130}
},

"score":
{
"pos": {"x": 5, "y": 3},
"template": "Punkte: $1",
"value": 0
}
},

"view":
{
"buttonStartStop":
{
"elementID": "button_start_stop"
},

"ball":
{
"color": "#55AA55",
"borderWidth": 1,
"borderColor": "#000000"
},

"paddle":
{
"color": "#aa55cc",
"borderWidth": 1,
"borderColor": "#000000"
},

"info":
{
"color": "#000000",
"font": "bold 25px Verdana, Geneva, sans-serif",
"textAlign": "center"
},

"score":
{
"color": "#000000",
"font": "bold 20px \"Courier New\", Courier, monospace",
"textBaseline": "top"
}
},

"control":
{
"player":
{
"left": {"key": "ArrowLeft", "keyCode": 37},
"right": {"key": "ArrowRight", "keyCode": 39}
}
}
}
</source>

Wenn Sie alles richtig gemacht haben, sollten Sie jetzt die Datei „<code>index.html</code>“ im Browser fehlerfrei laden können.
Diese Datei hat noch keine Inhalte, mit Ausnahme eines leeren Canvas-Elements. In der Browser-Konsole sollten aber keine Fehler gemeldet werden.

Es ist allerdings ziemlich unbefriedigend, wenn man eine Web-Anwendung ausführt und überhaupt nichts zu sehen ist,
obwohl etwas passiert. Öffnen Sie in den Browser-Entwicklertools die Netzwerkansicht und laden Sie die HTML-Datei erneut. Dann sollten Sie sehen,
dass 23 Dateien geladen werden. (Hier ist später noch Optimierungsarbeit angesagt. Die Anzahl der Dateien muss reduziert und die Inhalte müssen komprimiert werden.
Das ist aber nicht Thema dieses Tutoriums.)

Sie können probehalber auch mal <code>console.log</code>-Befehle in die einzelnen Dateien einfügen, damit Sie sehen in welcher Reihenfolge die Module geladen werden.

<source lang ="javascript">
console.log('Modul "MODULNAME" wird geladen');
// Ersetzen Sie MODULNAME durch den Namen des aktuellen Moduls.

define
( [],
function()
{ "use strict";

console.log('Modul "MODULNAME" wurde geladen');
// Ersetzen Sie MODULNAME durch den Namen des aktuellen Moduls.

return null;
}
);
</source>

Als Musterlösung gibt es das Projekt [https://glossar.hs-augsburg.de/beispiel/tutorium/es5/minipong/WK_MiniPong04/ WK_MiniPong04_empty (SVN)].
Die darin enthaltene Datei <code>[https://glossar.hs-augsburg.de/beispiel/tutorium/es5/minipong/WK_MiniPong04_empty/web/index.html index.html]</code>
verwendet allerdings den Befehl „<code>terminal.log</code>“, den Sie als Übungsaufgabe im Praktikum erstellen sollten. Damit werden die Log-Nachrichten
im HTML-Dokument und nicht in der Browser-Konsole ausgegeben. Außerdem wurde der Logging-Code etwas erweitert, sodass anhand von Einrückungen
zu sehen ist, welcher Code von welchem Modul geladen wird.

==Models und Views==

===Ball===
[[Datei:MiniPong04 ClassModel Ball.png|gerahmt|rechts|Ball-View und Ball-Model]]

In den vorangegangenen Teilen des Tutoriums war der Ball ständig sichtbar und ständig in Bewegung. Das heißt,
es wurden nur folgende Attribute und Methoden benötigt:

* <code>r</code> (Radius)
* <code>x</code> (aktuelle $x$-Position)
* <code>y</code> (aktuelle $y$-Position)
* <code>vx</code> (aktuelle Geschwindigkeit in $x$-Richtung)
* <code>vy</code> (aktuelle Geschwindigkeit in $y$-Richtung)
* <code>move(p_seconds)</code> (Bewegen des Balls an die neue Position, die sich aus der aktuellen Position, der Geschwindigkeit und der Anzahl der Sekunden seit der letzten Berechnung der Position ergibt)

Im eigentlichen Spiel werden jedoch viel mehr Attribute und Methoden benötigt. Der Ball ist beim Start der Web-Anwendung zunächst unsichtbar,
erst beim Spielstart wird er sichtbar gemacht

* <code>visible</code> (Flag, ob der Ball sichtbar oder unsichtbar ist)
* <code>show()</code> (Methode, um den Ball sichtbar zu machen)
* <code>hide()</code> (Methode, um den Ball unsichtbar zu machen)

Solange der Ball unsichtbar ist, bewegt er sich nicht (<code>vx === 0</code> und <code>vy === 0</code>) und befindet sich an seiner Startposition
(<code>x === x_start</code> und <code>y === y_start</code>). Bei einem Reset des Spiels werden Position und Geschwindigkeit auf passende Startwerte gesetzt.
Diese werden dem Konstruktor „<code>ModelBall</code>“ im Parameter „<code>p_init</code>“ übergeben und vom Konstruktor dann in folgenden Attribute gespeichert:
* <code>x_start</code> ($x$-Koordinate der Startposition)
* <code>y_start</code> ($y$-Koordinate der Startposition)
* <code>vx_start_min</code> (minimale Startgeschwindigkeit in $x$-Richtung)
* <code>vx_start_max</code> (maximale Startgeschwindigkeit in $x$-Richtung)
* <code>vy_start_min</code> (minimale Startgeschwindigkeit in $y$-Richtung)
* <code>vy_start_max</code> (maximale Startgeschwindigkeit in $y$-Richtung)

Man beachte, dass der Ball bei jedem Spielstart von derselben Position aus startet, aber dass die Startgeschwindigkeit (in Grenzen) zufällig gewählt wird.

Um das Spiel starten, beenden und neu starten zu können, werden drei weitere Methoden benötigt:
* <code>reset()</code> (Ball anhalten, unsichtbar machen und auf die Startposition setzen)
* <code>start()</code> (Ball auf eine zufällige Startgeschwindigkeit setzen)
* <code>stop()</code> (Ball anhalten, {{dh}}, die Geschwindigkeit auf Null setzen)

Insgesamt ergibt sich damit folgender Code:

'''Konstruktor'''
<source lang="javascript">
function ModelBall(p_init)
{
this.r = p_init.r;

this.x_start = p_init.pos.x;
this.y_start = p_init.pos.y;
this.vx_start_min = p_init.vel.x.min;
this.vx_start_max = p_init.vel.x.max;
this.vy_start_min = p_init.vel.y.min;
this.vy_start_max = p_init.vel.y.max;

this.reset(); // initializes further attributes
}
</source>

'''Öffentliche Methoden'''
<source lang="javascript">
ModelBall.prototype =
{
reset:
function()
{
this.stop(); // By default, the ball does not move around.
this.hide(); // By default, the ball is invisible.

this.x = this.x_start;
this.y = this.y_start;
},

show:
function() { this.visible = true; },

hide:
function() { this.visible = false; },

stop:
function()
{
this.vx = 0;
this.vy = 0;
},

start:
function()
{
// react only if the ball is not already moving
if (this.visible === true && this.vx === 0 && this.vy === 0)
{
this.vx = (Math.random() < 0.5 ? 1 : -1)*
(this.vx_start_min +
Math.random()*(this.vx_start_max - this.vx_start_min)
);
this.vy = (Math.random() < 0.5 ? 1 : -1)*
(this.vy_start_min +
Math.random()*(this.vy_start_max - this.vy_start_min)
);
}
},

move:
function(p_seconds)
{
this.x += this.vx * p_seconds;
this.y += this.vy * p_seconds;
}
};
</source>

Fügen Sie diesen Code in den Rumpf der Callback-Funktion in der Datei „<code>model/ball.js</code>“ ein. Vergessen Sie nicht,
in dieser Callback-Funktionen den Return-Befehl
<source lang="javascript">
return null;
</source>
durch den Return-Befehl
<source lang="javascript">
return ModelBall;
</source>
zu ersetzen.

Die Ball-View ändert sich nur in einem Aspekt gegenüber der Version aus dem zweiten und dritten Teil des Tutoriums.
Die Draw-Funktion darf den Ball nur zeichnen, wenn er sichtbar ist. Kopieren Sie also den Inhalt der Datei
[https://glossar.hs-augsburg.de/beispiel/tutorium/es5/minipong/WK_MiniPong03/web/js/app/view/ball.js <code>view/ball.js</code>]
aus dem dritten Teil des Tutoriums in die neue Datei <code>view/ball.js</code> und fügen Sie die If-Anweisung
<source lang="javascript">
if (this.model.visible === true)
</source>
vor den eigentlichen Zeichenbefehl „<code>p_context.drawImage</code>“ ein.

===Paddle===
[[Datei:MiniPong04 ClassModel Paddle.png|gerahmt|rechts|Schläger-Model und Schläger-View]]

Der Schläger ist sehr ähnlich aufgebaut wie der Ball. (Der Code ist also nicht [[DRY]]. Man sollte zwei allgemeine Klassen „<code>ModelGeoObject</code>“
und „<code>ViewGeoObject</code>“ definieren, von denen alle Geo-Objekt-Klassen wie „<code>ModelBall</code>“, „<code>ViewBall</code>“ gemeinsame
Eigenschaften erben.)

Dem Schläger ist neben Position und Geschwindigkeit auch noch eine Beschleunigung zugeordnet.
Für alle drei Vektoren sind feste Startwerte vorgegeben, {{dh}} der Schläger befindet sich bei Spielbeginn stets an derselben Stelle,
startet, sobald der Benutzer ihn bewegt, mit derselben Geschwindigkeit und wird stets im gleichen Maße schneller, je länger der
Spieler die entsprechende Steuertaste gedrückt hält.

Gegenüber dem Ball gibt es ein weiteres Attribut, das für die Realisierung der Use Cases wichtig ist:

* <code>friction</code> (Reibung, genauer Reibungsfaktor)

Wenn sich der Schläger bei eine Kollision mit dem Ball bewegt, wird der Ball aufgrund der Reibung kurzzeitig vom Schläger in $x$-Richtung
mitgezogen. Das heißt, die $x$-Geschwindigkeit des Schlägers ändert sich. Diese wird berechnet, indem zur $x$-Geschwindigkeit
des Balls die $x$-Geschwindigkeit mal dem Reibungsfaktor des Schlägers addiert wird. Wenn die Reibung gleich Null ist hat also bei einer Kollision
die Geschwindigkeit des Schlägers keine Auswirkung auf die Geschwindigkeit des Balls. Je größer der Reibungsfaktor gewählt wird, desto größer ist die Ablenkung.
In der Musterlösung wurde der Reibungsfaktor auf $0,3$ gesetzt.

Zu guter Letzt werden noch vier berechnete Attribute für den Schläger definiert:

* <code>get left() { return this.x; }</code> (linke $x$-Koordinate des Schlägers)
* <code>get right() { return this.x + this.width; }</code> (rechte $x$-Koordinate des Schlägers)
* <code>get top() { return this.y; }</code> (linke $y$-Koordinate des Schlägers)
* <code>get bottom() { return this.y + this.height; }</code> (rechte $y$-Koordinate des Schlägers)

Diese Attribute vereinfachen die Kollisionsfunktionen etwas, bei denen mehrfach auf die verschiedenen Seiten des Schlägers zugegriffen werden muss.

Insgesamt sieht die Implementierung des Schlägermodells folgendermaßen aus:

'''Konstruktor'''
<source lang="javascript">
function ModelPaddle(p_init)
{
this.width = p_init.width;
this.height = p_init.height;

this.x_start = p_init.pos.x;
this.y_start = p_init.pos.y;
this.vx_start = p_init.vel.x;
this.vy_start = p_init.vel.y;
this.ax_start = p_init.acc.x;
this.ay_start = p_init.acc.y;

this.friction = p_init.friction;

this.reset(); // initializes further attributes
}
</source>

'''Öffentliche Methoden'''
<source lang="javascript">
ModelPaddle.prototype =
{
reset:
function()
{
this.stop(); // By default, the paddle does not move around.
this.hide(); // By default, the paddle is invisible.

this.x = this.x_start;
this.y = this.y_start;
},

show:
function()
{ this.visible = true; },

hide:
function()
{ this.visible = false; },

stop:
function()
{ this.vx = 0;
this.vy = 0;

this.ax = 0;
this.ay = 0;
},

start:
function(p_direction)
{
// react only if the paddle is visible not already moving
if (this.visible === true &&
this.vx === 0 && this.vy === 0
)
{
switch (p_direction)
{
case "left":
this.vx = -this.vx_start;
this.ax = -this.ax_start;
break;
case "right":
this.vx = this.vx_start;
this.ax = this.ax_start;
break;

case "up":
this.vy = -this.vy_start;
this.ay = -this.ay_start;
break;
case "down":
this.vy = this.vy_start;
this.ay = this.ay_start;
break;
}
}
},

move:
function(p_seconds)
{ this.x += this.vx * p_seconds;
this.y += this.vy * p_seconds;
this.vx += this.ax * p_seconds;
this.vy += this.ay * p_seconds;
},

/** The left side of the paddle (read only). */
get left() { return this.x; },

/** The right side of the paddle (read only). */
get right() { return this.x + this.width; },

/** The top side of the paddle (read only). */
get top() { return this.y; },

/** The bottom side of the paddle (read only). */
get bottom() { return this.y + this.height; }
};
</source>

Beachten Sie, dass es hier empfehlenswert ist, das Prototyp-Objekt des Konstruktors nicht mit mehrere Befehle der Art
<source lang="javascript">
ModelPaddle.prototype.reset = function(){...};
ModelPaddle.prototype.show = function(){...};
ModelPaddle.prototype.hide = function(){...};
...
</source>
zu befüllen, sondern ein eigenes Prototyp-Objekt zu definieren:
<source lang="javascript">
ModelPaddle.prototype =
{
reset: function(){...},
show: function(){...},
hide: function(){...},
...
get left() { return this.x; },
get right() { return this.x + this.width; },
...
};
</source>

Der Grund ist, dass es keine einfache Syntax gibt, eine Getter- oder einer Setter-Methode zu einem
bestehenden Objekt hinzuzufügen. Im obigen Beispiel müsste man beispielsweise Folgendes schreiben,
um Getter-Methoden zum Objekt „<code>ModelPaddle.prototype</code>“ nachträglich hinzuzufügen:

<source lang="javascript">
Object.defineProperty(ModelPaddle.prototype,
'left',
{ get: function() { return this.x; } }
);
Object.defineProperty(ModelPaddle.prototype,
'right',
{ get: function() { return this.x + this.width; } }
);
...
</source>

===Text===
[[Datei:MiniPong04 ClassModel Text.png|gerahmt|rechts|Text-Model und Text-View]]

Im Spiel „MiniPong“ gibt es zwei Textfelder: Eines zum Anzeigen des Scores und eines zum Anzeigen von allgemeinen Informationen.
Im Gegensatz zu Ball und Schläger bewegt sich ein Text (in diesem Spiel!) nicht. Daher benötigt man im Model wesentlich weniger Attribute und Methode.

* <code>x</code> ($x$-Position des Text-Aufhängepunkt)
* <code>y</code> ($y$-Position der Text-Baseline)
* <code>template</code> (ein optionaler String, der die Zeichenfolge „<code>$1</code>“ enthält)
* <code>value</code> (der Wert, der im Textfeld dargestellt werden soll)
* <code>text</code> (ein Read-only-Attribut: „<code>return template.replace('$1', value)</code>“)
* <code>visible</code> (Sichtbarkeit des Textes)

Das zugehörige View-Objekt legt das Aussehen des Textes fest:

* <code>color</code> (Textfarbe)
* <code>font</code> (Textfont, analog zu CSS-Fonts)
* <code>textAlign</code> ([http://www.w3schools.com/tags/canvas_textalign.asp Aufhängepunkt}: <code>left</code>, <code>center</code>, <code>right</code>)
* <code>textBaseline</code> ([http://www.w3schools.com/tags/canvas_textbaseline.as Baseline}: <code>top</code>, <code>bottom</code>, <code>middle</code>, <code>alphabetic</code>, <code>hanging</code>)

Damit sollte eigentlich klar sein, wie die Model- und die View-Klasse aussehen-
Fügen Sie diesen Code in den Rumpf der Callback-Funktion in der Datei „<code>model/text.js</code>“ ein. Vergessen Sie nicht,
in dieser Callback-Funktionen den Return-Befehl
<source lang="javascript">
return null;
</source>
durch den Return-Befehl
<source lang="javascript">
return ModelText;
</source>
zu ersetzen.

'''<code>ModelText</code>: Konstruktor'''
<source lang="javascript">
function ModelText(p_init)
{
this.x = p_init.pos.x;
this.y = p_init.pos.y;

this.template = p_init.template;
this.value = p_init.value;

this.visible = true;
}
</source>

'''<code>ModelText</code>: Öffentliche Methoden'''
<source lang="javascript">
ModelText.prototype =
{
// read only attribute
get text()
{ return (this.value == null)
? ''
: (this.template == null)
? this.value.toString()
: this.template.replace('$1', this.value);
}
};
</source>

Die View-Klasse ist auch nicht viel komplexer. Auf die Vorberechnung
eine Mini-Canvas, der anstelle des Textes in den Haupt-Canvas kopiert wird, wird hier verzichtet.
Da sich der Text-Inhalt ändern kann und üblicherweise auch regelmäßig ändert, müsste man
bei jeder Text-Änderung einen neuen derartigen Mini-Canvas erstellen. Das ist zwar möglich,
führt hier aber zu weit.

'''<code>ViewText</code>: Konstruktor'''
<source lang="javascript">
function ViewText(p_model, p_init /*, p_document*/)
{
this.model = p_model;

this.color = p_init.color || 'black';
this.font = p_init.font || 'normal';
this.textAlign = p_init.textAlign || 'left';
this.textBaseline = p_init.textBaseline || 'alphabetic';
}
</source>

'''<code>ViewText</code>: Öffentliche Methoden'''
<source lang="javascript">
ViewText.prototype.draw =
function(p_context)
{
var l_model = this.model;

if (l_model.value == null || l_model.value.toString() === '')
return;

// ALL font attributes must be set, as it cannot be
// guaranteed that another module has changed some font
// attributes before.
p_context.font = this.font;
p_context.textAlign = this.textAlign;
p_context.textBaseline = this.textBaseline;
p_context.fillStyle = this.color;
p_context.fillText(l_model.text,
(this.textAlign === 'center')
? p_context.canvas.clientWidth/2
: l_model.x,
l_model.y
);
};
</source>

'''Haben Sie an die Return-Anweisung „<code>return ViewText;</code>“ gedacht? '''

===Button===
[[Datei:MiniPong04 ClassModel Button.png|gerahmt|rechts|Button-Model und Button-View]]

Einen grafischen Button, der im Canvas dargestellt wird, könnte man mit Hilfe eines Rechtecks oder Kreises und eines Textes realisieren.
Button-Klicks müsste man dann mit Hilfe eine Kollisionserkennung („Mausspitze kollidiert mit Button“) und -behandlung verarbeiten.

Hier soll ein einfacherer Weg eingeschlafen werden: Als Button wird ein HTML-Button verwendet, der sich
außerhalb der Bühne befindet. Folgende Attribute sind in einem Model-Objekt enthalten:

* <code>label</code> (Der Text, mit dem der Button im HTML-Dokument beschriftet sein soll.)
* <code>class</code> (Ein CSS-Klassen-Name, der dem Button-Element im HTML-Dokument zugeordnet wird. Beispielsweise kann man eine CSS-Klasse „<code>.hidden</code>“ definieren, mit dem man den Button unsichtbar machen kann.)
* <code>onClick</code> (Eine Methode, die aufgerufen wird, sobald der Button geklickt wird.)

Der Konstruktor übernimmt für diese Attribute wie üblich alle Initialwerte aus einen Init-Objekt namens „<code>p_init</code>“. Ein Problem besteht dabei allerdings.
Das Init-Objekt wird üblicherweise aus einer JSON-Datei eingelesen. Eine derartige Datei kann keine JavaScript-Funktionen enthalten.
Das heißt, das Attribut „<code>onClick</code>“ wird üblicherweise mit „<code>null</code>“ initialisiert. Es ist dann die Aufgabe einer Logikkomponente
diesem Attribut zur rechten Zeit eine geeignete Prozedur zuzuweisen.

'''ModelButton: Konstruktor'''
<source lang="javascript">
function ModelButton(p_init)
{
this.label = p_init.label || null;
this.class = p_init.class || null;
this.onClick = p_init.onClick || null;
}
</source>

Die View ist auch nicht sonderlich kompliziert.
Der Konstruktor speichert wie üblich das zugehörige Model im Attribut „<code>model</code>“.
Außerdem sucht er im HTML-Dokument denjenigen Button, der mit dem Model verknüpft werden soll.

'''ViewButton: Konstruktor'''
<source lang="javascript">
function ViewButton(p_model, p_init, p_document)
{
this.model = p_model;
this.element = p_document.getElementById(p_init.elementID);
}
</source>

Sie Draw-Methode macht nichts weiter, als alle Attribute, die im Model definiert sind,
in das zugehörige HTML-Button-Element zu kopieren, sofern das jeweilige Attribut im Model
definiert ist und sich vom im HTML-Button-Element gespeicherten Wert unterscheidet.

'''ViewButton: Öffentliche Methoden'''
<source lang="javascript">
ViewButton.prototype.draw =
function()
{
var l_model = this.model,
l_element = this.element;

if (l_model.label != null && l_element.innerHTML !== this.model.label)
{ l_element.innerHTML = this.model.label; }
if (l_model.class != null && l_element.className !== this.model.class)
{ l_element.className = this.model.class; }
if (l_model.onClick != null && l_element.onclick !== this.model.onClick)
{ l_element.onclick = this.model.onClick; }
};
</source>

Da die Draw-Methode regelmäßig aufgerufen wird (ca. 60 mal pro Sekunde),
ändert sich das Aussehen und/oder das Verhalten des Button automatisch mit
jeder Änderung des Models.

Eigentlich ist das ein Overkill. So eine Änderung des Button-Labels und des Button-Verhaltens
passiert nur ein paar mal pro Spiel.
Hätte die Logik eine direkten Zugriff auf die View, könnte man es sich sparen,
den Button durch die View-Loop aktualisieren zu lassen.
Wenn man der Spiellogik – aus gutem Grund – keinen direkten Zugriff auf die View gewähren will
und man den Button auch nicht viele Dutzend mal pro Sekunde aktualisieren will, hilft der Einsatz des
so genannten [[Observer-Pattern]]s weiter. Dies soll hier aber nicht weiter verfolgt werden.

==Keyboard-Controller==
[[Datei:MiniPong04 ClassModel controlKeyboard.png|gerahmt|rechts|Der Keyboard-Controller]]

Der Controller zum Steuern des Paddles per Tastatur ändert sich nicht. Er kann eins zu eins
[https://glossar.hs-augsburg.de/beispiel/tutorium/es5/minipong/WK_MiniPong03/web/js/app/control/keyboard.js aus dem dritten Teil des Tutoriums übernommen]
und in die Datei <code>controller/keyboard.js</code> eingefügt werden.

==Kollisionserkennung und -behandlung==
[[Datei:MiniPong04 ClassModel Collision.png|gerahmt|rechts|Hilfsprozeduren für Kollisionserkennung und -behandlung]]

Im [[HTML5-Tutorium:_Canvas:_MiniPong_03|dritten Teil des Tutoriums]] wurde die Kollisionserkennung und -behandlung
als Teil des Models angesehen. Ihre einzige Aufgabe war es, Geschwindigkeit und Position von beweglichen Objekten
im Falle von Kollisionen zu korrigieren. Nun kommt noch eine weitere Aufgabe hinzu. Sie muss die Spiellogik über
Kollisionen informieren, die das Spielgeschehen beeinflussen. Im Fall von MiniPong sind das die Kollision von Schläger und Ball
(Punktgewinn) sowie die Kollision von Schläger und unterem Bühnenrand (Spielende).

Bislang gab es lediglich ein Modul namens
„<code>[https://glossar.hs-augsburg.de/beispiel/tutorium/es5/minipong/WK_MiniPong03/web/js/app/model/collision.js|collision.js]<code>“
zur Kollisionsbehandlung. Dieses Modul droht zum Giganten zu werden, wenn immer mehr und mehr Kollisionsarten behandelt werden müssen.
Daher wird es in mehrere Teilmodule aufgespalten.

Die Kollisionsprozedur „<code>collisionStagePaddle</code>“ kann eins zu eins vom dritten Teil des Tutoriums übernommen werden,
da die Kollision des Paddles mit der Wand keine Auswirkung auf das Spielgeschehen hat. Diese Kollision bewirkt lediglich,
dass der Schläger gestoppt wird. Und das erledigt die Prozedur von sich aus. Allerdings gibt es durchaus Situationen, in denen auch
eine Kollision zwischen Schläger und Wand von der Spiellogik behandelt werden muss. Beispielsweise kann man im Breakout-Spiel [[Wikipedia:Bolo|Bolo]]
mit dem Schläger gegen die Wand „donnern“. Wenn man dies fest genug macht, wenn also der Schläger bei der Kollision mit der Wand eine gewisse
Geschwindigkeit hat, wird der Raum leicht erschüttert. Dies hat auch Auswirkungen auf den Ball, dessen Geschwindigkeitsvektor dadurch leicht verändert wird.
Auf diese Weise kann man den Ball, wenn er irgendwo feststeckt, häufig wieder frei bekommen.

Die folgende Implementierung der Kollisionsprozedur „<code>collisionStagePaddle</code>“ unterscheidet sich in einer Hinsicht von der ursprünglichen
Implementierung. Anstatt die Ränder des Schlägers zu berechnen, werden die neuen Schläger-Attribute „<code>left</code>“, „<code>right</code>“, „<code>top</code>“ und „<code>bottom</code>“ verwendet. Fügen Sie diesen Code ins Modul „<code>collision/stage_paddle</code>“ ein (und vergessen Sie nicht, den Return-Befehl anzupassen).

<source lang="javascript">
function collisionStagePaddle(p_stage, p_paddle)
{
// If the paddle collides with the left wall of the stage,
// stop it and move it back to the stage.
if (p_paddle.vx < 0 && p_paddle.left <= 0)
{
p_paddle.stop();
p_paddle.x = 0;
}

// If the paddle collides with the right wall of the stage,
// stop it and move it back to the stage.
if (p_paddle.vx > 0 && p_paddle.right >= p_stage.width)
{
p_paddle.stop();
p_paddle.x = p_stage.width - p_paddle.width;
}

// If the paddle collides with the top wall of the stage,
// stop it and move it back to the stage.
if (p_paddle.vy < 0 && p_paddle.top <= 0)
{
p_paddle.stop();
p_paddle.y = 0;
}

// If the paddle collides with the bottom wall of the stage,
// stop it and move it back onto the stage.
if (p_paddle.vy > 0 && p_paddle.bottom >= p_stage.height)
{
p_paddle.stop();
p_paddle.y = p_stage.height - p_paddle.height;
}
}
</source>

Die Kollisionsprozedur „<code>collisionStageBall</code>“ ist im Modul „<code>collision/stage_ball</code>“ enthalten.
Die Prozedur kann allerdings nicht eins zu eins vom dritten Teil des Tutoriums übernommen werden, da die Kollision mit
der unteren Wand anders behandelt werden muss, als die Kollision mit den übrigen Wänden.

Bei einer Kollision mit der unteren Wand wird das Spiel beendet. Für die Behandlung des Spielendes ist die
Spiellogik zuständig. Um über diese Art der Kollision benachrichtigt zu werden, übergibt sie der
Kollisionsprozedur „<code>collisionStageBall</code>“ im Parameter „<code>cb_hit</code>“ eine Callback-Funktion,
die im Falle einer Kollision mit der unteren Wand aufgerufen werden soll. Damit die Spiel erst endet,
wenn der Ball die Bühne vollständig verlassen hat, wird die untere Wand etwas nach unten in den nicht sichtbaren Bereich
verschoben.

<source lang="javascript">
function collisionStageBall(p_stage, p_ball, cb_exit)
{
// If the ball collides with the left or the right wall of the stage
// mirror its x-velocity and move the ball back onto the stage.
if (p_ball.x <= p_ball.r)
{
p_ball.vx = -p_ball.vx;
p_ball.x += 2*(p_ball.r - p_ball.x);
}
if (p_ball.x >= p_stage.width - p_ball.r)
{
p_ball.vx = -p_ball.vx;
p_ball.x -= 2*(p_ball.r - p_stage.width + p_ball.x);
}

// If the ball collides with the top wall of the stage
// mirror its y-velocity and move the ball back onto the stage.
if (p_ball.y <= p_ball.r)
{
p_ball.vy = -p_ball.vy;
p_ball.y += 2*(p_ball.r - p_ball.y);
}

// If the ball leaves the bottom of the stage, call cb_exit.
// Factor 1.5: The ball is really outside the stage an thus invisible,
// even if the view draws a very thick border around it.
if (p_ball.y >= p_stage.height + 1.5*p_ball.r)
{ if (cb_exit)
cb_exit();
}
}
</source>

Zu guter Letzt muss noch die Kollisionserkennung und -behandlung für Kollisionen des Balls mit dem Schläger
realisiert werden. Über jede derartige Kollision wird die Spiellogik ebenfalls mit einer Callback-Funktion informiert,
damit letztere den Punktestand aktualisieren kann.

Die nachfolgende Implementierung der Kollisionserkennung und -behandlung ist ziemlich primitiv, da nur zwei Fälle
unterschieden werden: Kollision des Balles mit der oberen oder der unteren Seite des Schlägers. Das reicht
zunächst für unsere Zwecke, führt aber schon zu Problemen, wenn ein senkrechter Schläger an einer Seitenwand
verwendet werden soll. In diesem Fall müsste die Kollisionsprozedur umgeschrieben werden.

Bei einer korrekten Kollisionserkennung und -behandlung zwischen Kreis und Rechteck müssen 8 Fälle unterschieden werden:
Kollision des Balls mit einer der vier Seitenwände sowie Kollision des Balls mit einer der vier Ecken.

<source lang="javascript">
function collisionBallPaddle(p_ball, p_paddle, cb_hit)
{
if (p_ball.y + p_ball.r >= p_paddle.top &&
p_ball.y + p_ball.r <= p_paddle.bottom &&
p_ball.x + 0.5*p_ball.r >= p_paddle.left &&
p_ball.x - 0.5*p_ball.r <= p_paddle.right
)
{
// Resolve penetration.
if (p_ball.vy > 0) // The ball is moving from top to bottom.
{ p_ball.y = p_paddle.top - p_ball.r; }
else // The ball is moving from bottom to top.
{ p_ball.y = p_paddle.bottom + p_ball.r; }

// Modify the velocity of the ball.
p_ball.vy = -p_ball.vy;
p_ball.vx += p_paddle.friction*p_paddle.vx;

// If the paddle hits the ball, invoke the callback function.
if (cb_hit)
{ cb_hit(); }
}
}
</source>

==Model- und View-Loop==
[[Datei:MiniPong04 ClassModel Loop.png|gerahmt|rechts|Model-Loop und View-Loop]]

Die Model-Loop sowie die View-Loop waren bislang Bestandteile des Moduls
„<code>[https://glossar.hs-augsburg.de/beispiel/tutorium/es5/minipong/WK_MiniPong03/web/js/app/minipong.js minipong.js]</code>“. Da dieses Modul deutlich größer wird,
sollte es zerschlagen werden. Für die MiniPong-Anwedung wird es in vier Einzelmodule unterteilt:

* <code>init</code> (Erzeugung aller wesentlichen Objekte; Starten der View Loop; Verknüpfung des Keyboard-Controllers mit dem Paddle)
* <code>ViewLoop</code> (Visualisierung der aktuellen Zustände der grafischen Objekte des Spiels)
* <code>ModelLoop</code> (Berechnung der Positionen der beweglichen Objekte des Spiels; Information der Spiellogik über bestimmte Kollisionen)
* <code>minipong</code> (Die Spiellogik)

Zunächst werden die beiden Loops in eigenständige Module ausgelagert. Beide Module werden als Klassen realisiert.
Das heißt, es müssen jeweils ein <code>ViewLoop</code>- und ein <code>ModelLoop</code>-Objekt erzeugt werden.
Diese Objekte kennen jeweils zwei Methoden <code>start</code> und <code>stop</code>, den denen die Loops
gestartet und auch wieder angehalten werden können. Im Falle der View-Loop ist das für das Spiel MiniPong nicht
sonderlich wichtig, da diese View nur einmal gestartet wird und dann dauerhaft aktiv ist. Bei einer komplexeren Web-Anwendung
solle man allerdings versuchen, die View-Loop nur während des eigentlichen Spiels zu aktivieren. So eine Loop
kostet Rechenpower und belastet damit insbesondere den Akku von mobilen Geräten.

Die Model-Loop muss auch schon von der MiniPong-Spiellogik gestartet und gestoppt werden können. Dies wird insbesondere
bei einer erweiterten Variante deutlich, bei dem das Spiel durch eine Pause-Taste temporär angehalten werden kann
([https://glossar.hs-augsburg.de/beispiel/tutorium/es5/minipong/WK_MiniPong04/web/index_pause.html index_pause.html]).

Die View-Loop erhält als Argumente das Fenster in dem die Web-Anwendung läuft, einen Canvas, auf dem grafische Objekte visualisiert werden sollen
sowie eine Liste, die die Views dieser Objekte enthält. Die View-Loop löscht zu Beginn den Canvas und ruft dann für alle View-Objekte die
Methode „<code>draw</code>“ auf. Dieser übergibt sie als Argument den 2D-Context des Canvas-Elements. Allerdings ist die Draw-Methode nicht
verpflichtet, ein Objekt auf den Canvas zu zeichnen. Sie kann auch ein Objekt im DOM-Baum des HTML-Dokuments aktualisieren.
Dies macht beispielsweise die Draw-Methode des Button-Objekts.

'''ViewLoop: Konstruktor'''
<source lang="javascript">
function ViewLoop(p_window, p_canvas, p_views)
{
var l_context = p_canvas.getContext("2d"),
n = p_views.length;

this.v_window = p_window;

this.m_update_view =
function m_update_view()
{
// clear canvas
l_context.clearRect(0, 0, p_canvas.width, p_canvas.height);

// draw all visual objects
for (var i = 0; i <n; i++ )
{ p_views[i].draw(l_context); }

p_window.requestAnimationFrame(m_update_view);
};
}
</source>

Aktiviert und am Laufen gehalten wird die View-Loop wie üblich mit Hilfe der Methode „<code>window.requestAnimationFrame</code>“.
Diese Methode liefert beim Aufruf eine Integerzahl zurück, die den Timer eindeutig identifiziert. Wenn man diesen Identifikator speichert,
kann man die rekursiven Aufrufe der Methode „<code>window.cancelAnimationFrame</code>“ unterbrechen und so die Loop anhalten.
Dies wird ausgenutzt, um die Start- und die Stopp-Methode zu realisieren.

'''ViewLoop:Öffentliche Methoden'''
<source lang="javascript">
ViewLoop.prototype =
{
start:
function()
{
if (this.v_timer == null)
{ this.v_timer = this.v_window.requestAnimationFrame(this.m_update_view); }
},

stop:
function()
{
if (this.v_timer != null)
{
this.v_window.cancelAnimationFrame(this.v_timer);
delete this.v_timer;
}
}
};
</source>

Der Model-Loop-Konstruktor erwartet als Input eine Kollisionsprozedur, die
(angestrebte) Update-Frequenz sowie eine Liste von Model-Objekten,
die bewegt werden sollen.

Der Konstruktor definiert ein „privates“ Attribut „<code>v_milliseconds</code>“ und eine „private“ Methode „<code>m_update_model</code>“
auf die die Start- und die Stop-Methode zugreifen können. (In Wirklichkeit handelt es sich um ein öffentliches Attribut und um eine öffentliche Methode,
da im Prototype-Objekt keine privaten Elemente definiert werden können. Ich kennzeichne private Elemente einfach mittels eines Namenszusatzes
„<code>v_...</code>“ – <code>v</code> für „(Zustands-)Variable“ – bzw. „<code>m_...</code>“ – <code>m</code> für „Methode“ – und weiß damit,
dass ich von außerhalb nicht auf derartige Elemente zugreifen darf.)

Die Methode „<code>m_update_model</code>“ ruft zunächst für alle Objekte die Move-Methode auf und führt anschließend (a posteriori)
mit Hilfe der Kollisionsprozedur eine Kollisionserkennung und -behandlung durch.

'''ModelLoop: Konstruktor'''
<source lang="javascript">
function ModelLoop(p_collision, p_f, p_models)
{
var l_seconds = 1 / p_f;
this.v_milliseconds = 1000 * l_seconds;

this.m_update_model =
function ()
{
// move around all movable objects
for (var i = 0, n = p_models.length; i < n; i++)
{ p_models[i].move(l_seconds); }

// detect and handle collision (a posteriori)
p_collision();
};
}
</source>

Die Model-Update-Methode soll regelmäßig alle <code>v_milliseconds</code> Millisekunden aufgerufen werden.
Dazu wird die JavaScript-Funktion „<code>setInterval</code>“ verwendet (die allerdings die Zeitvorgaben nicht sonderlich genau nimmt).
Diese Funktion liefert, wie auch schon <code>requestAnimationFrame</code>, beim Aufruf eine Integerzahl zurück,
mit der der Timer eindeutig identifiziert wird. Mit Hilfe dieses Identifikators und der Funktion „<code>clearInterval</code>“
kann man den Timer anhalten. Die Star- und die Stopp-Methoden können daher auf genau dieselbe Art realisiert werden,
wie bei der View-Loop:

'''ModelLoop:Öffentliche Methoden'''
<source lang="javascript">
ModelLoop.prototype =
{
start:
function()
{
if (this.v_timer == null)
{ this.v_timer = setInterval(this.m_update_model, this.v_milliseconds) }
},

stop:
function()
{
if (this.v_timer != null)
{
clearInterval(this.v_timer);
delete this.v_timer;
}
}
};
</source>

==Initialisierung==
[[Datei:MiniPong04 ClassModel init.png|gerahmt|rechts|Initialisierung der Web-Anwendung]]

Die Initialisierungsprozedur „<code>init</code>“ hat zwei Aufgaben: Zunächst muss sie alle wesentlichen Objekte erstellen
und anschließend die Anwendung zu Laufen bringen.

Sie erwartet zwei Argumente: das Fenster, in dem die Anwendung läuft und das Initialisierungsobjekt,
das in der JSON-Datei definiert wurde:
<source lang="javascript">
function init(p_window, p_init)
</source>

Anschließend muss sie die benötigten Objekte erstellen bzw. aus dem HTML-Dokument extrahieren.

Die View-Objekte benötigen das im Browser-Fenster enthalten HTML-Dokument sowie das
darin enthalten Canvas-Element. Auch der Keyboard-Controller benötigt das HTML-Dokument.

<source lang="javascript">
var l_canvas_init = p_init.canvas,
l_document = p_window.document,
l_canvas = l_document.getElementById(l_canvas_init.element),
</source>

Als nächstes müssen alle Model- und View-Objekte erzeugt werden, mit Ausnahme des <code>ModelStage</code>-Objekts.
(Als <code>ModelStage</code>-Objekt wird das Canvas-Init-Objekt verwendet. Es enthält die Größe und die Breite der Bühne,
und das ist alles was die Kollisionsprozedur von der Bühne wissen muss.)

Jedem Model-Objekt werden die Initialisierungsinformationen übergeben, die für das jeweilige Objekt im Initialisierungsobjekt
„<code>p_init</code>“ enthalten sind. Jedem View-Objekt werden nicht nur Initialisierungsinformationen aus dem
<code>p_init</code>-Objekt übergeben, sondern auch das Model, das es darstellen soll. Darüber hinaus benötigen
einige Objekte das Objekt „<code>p_dokument</code>“, um einen Mini-Canvas zum Cachen der grafischen Darstellung
des Models erstellen zu können.

<source lang="javascript">
l_model_button = new ModelButton(p_init.model.buttonStartStop),
l_view_button = new ViewButton(l_model_button, p_init.view.buttonStartStop, l_document),

l_model_ball = new ModelBall(p_init.model.ball),
l_view_ball = new ViewBall(l_model_ball, p_init.view.ball, l_document),

l_model_paddle = new ModelPaddle(p_init.model.paddle),
l_view_paddle = new ViewPaddle(l_model_paddle, p_init.view.paddle, l_document),

l_model_info = new ModelText(p_init.model.info),
l_view_info = new ViewText(l_model_info, p_init.view.info),

l_model_score = new ModelText(p_init.model.score),
l_view_score = new ViewText(l_model_score, p_init.view.score),
</source>

Als nächstes werden die soeben erzeugten Model- und View-Objekte in Container gesteckt,
damit sie möglichst einfach an die Spiellogik bzw. die View-Loop übergeben werden können.

Die Modelle werden in ein [[Hasharray]] (= JavaScript-Objekt) gepackt, da die Spiellogik
namentlich auf die Objekte zugreifen können muss.
für die View-Loop wird ein einfaches Array als Container eingesetzt, da diese einfach der
Reihe nach für alle View-Objekte die Draw-Methode aufruft.

<source lang="javascript">
l_models = { stage: l_canvas_init,
button: l_model_button,
ball: l_model_ball,
paddle: l_model_paddle,
info: l_model_info,
score: l_model_score
},

l_views = [ l_view_button, l_view_ball, l_view_paddle, l_view_info, l_view_score];
</source>

Wie üblich muss noch die Größe des Canvas angepasst werden. Diese Größe ist wie immer im Objekt
„<code>l_canvas_init</code>“ enthalten.

<source lang="javascript">
l_canvas.width = l_canvas_init.width;
l_canvas.height = l_canvas_init.height;
</source>

Zu guter Letzt muss Init-Prozedur eine View-Loop erzeugen und starten (das geht in einem Aufwasch,
die die Loop nicht mehr angehalten werden soll), den Keyboard-Controller dem Paddle zuweisen
und die Spiellogik starten.

Bei jedem dieser drei Aufrufe übergibt sie einige der zuvor erzeugten Objekte:

* <code>ViewLoop</code>: alle View-Objekte
* <code>controlKeyboard</code>: das Paddle-Model
* <code>minipong</code>: alle Model-Objekte

<source lang="javascript">
new ViewLoop(p_window, l_canvas, l_views).start();
controlKeyboard(p_window, p_init.control.player, l_model_paddle);
minipong(p_init.game, l_models);
</source>

==MiniPong==
[[Datei:MiniPong04 ClassModel minipong.png|gerahmt|rechts|MiniPong: Die Spiellogik]]

Nachdem das Modul „<code>logic/minipong</code>“ von allen übrigen Aufgaben befreit wurde, ist es nur noch für die Umsetzung der Spiellogik verantwortlich.

Sie erhält von der Init-Prozedur die für sie bestimmten Initialisierungswerte sowie die Model-Objekte, die sie manipulieren kann und soll.
<source lang="javascript">
function minipong(p_init, p_models)
</source>

Zunächst speichert sie alle Model-Objekte in lokalen Variablen. Das hat den Vorteil, dass sie nicht immer
Aufrufe der Art „<code>p_models.xyz</code>“ tätigen muss. Außerdem legt sie ein leeres Array „<code>l_models_movable</code>“
an, das später alle beweglichen Model-Objekte enthält, {{dh}} alle Model-Objekte, für die die Methode „<code>l_move</code>“
existiert. Zu guter Letzt legt sie in der Variablen „<code>l_model_loop</code>“ eine Model-Loop an, die die Position und Geschwindigkeit
der beweglichen Objekte regelmäßig aktualisiert. Als Kollisionsprozedur wird diesem Objekt die Funktion „<code>f_collision</code>“
übergeben. Diese Funktion wird weiter unten im Funktionsrumpf von <code>minipong</code> definiert.

<source lang="javascript">
var l_stage = p_models.stage,
l_button = p_models.button,
l_info = p_models.info,
l_score = p_models.score,
l_ball = p_models.ball,
l_paddle = p_models.paddle,
l_models_movable = [],
l_model_loop = new ModelLoop(f_collision, p_init.fps, l_models_movable);
</source>

Nun ist es an der Zeit, das Array „<code>l_models_movable</code>“ zu befüllen. Dazu wird einfach die Liste mit
allen Model-Objekt durchlaufen. Alle Objekte, die die Methode „<code>move</code>“ enthalten werden in dieses Array eingefügt.
<source lang="javascript">
// Store all model objects that have a move method within the array l_models_movable.
for (var k in p_models)
{ if (p_models.hasOwnProperty(k) && p_models[k].move != null)
{ l_models_movable.push(p_models[k]); }
}
</source>

Mit den letzten beiden Anweisunges startet „<code>minipong</code>“ die Anwendung. Sie ruft
dazu die Prozedur „<code>f_stop</code>“ auf (da der Benutzer das Spiel erst mittel eine Klicks auf den Start-Knopf starten muss) und schreibt eine
Willkommensbotschaft in Info-Textfeld (und überschreibt damit die Meldung, die die Stopp-Funktion ins Info-Textfeld geschrieben hat.).

<source lang="javascript">
// Stop the game and display a welcome message.
f_stop();
l_info.value = p_init.welcome;
</source>

Nun müssen noch vier Prozeduren definiert werden, die in verschiedenen Spielsituationen aufgerufen werden.
Alle vier Prozeduren werden '''im Rumpf''' der Prozedur „<code>minipong</code>“ definiert. Das heißt, nur
<code>minipong</code> kann auf diese Prozeduren zugreifen. Sie kann sie allerdings als Callback-Funktionen
an andere Prozeduren und Methoden weiterleiten. Und genau das macht sie auch.

Ganz wichtig für die Spiellogik ist die Definition einer geeigneten Kollisionsprozedur,
die der Model-Loop übergeben wird, um die Kollisionserkennung und -behandlung damit durchzuführen.
Diese Prozedur verwendet die drei Hilfsprozeduren „<code>collisionBallPaddle</code>“, „<code>collisionCanvasBall</code>“ und „<code> collisionStagePaddle</code>“,
die einfach nacheinander aufgerufen werden.

Zwei dieser Prozeduren erwarten als Input eine Callback-Funktion, die im Falle von bestimmten Kollisiones von der Kollisionsbehandlung aufgerufen werden.
Die Prozedur „<code>collisionBallPaddle</code>“ ruft die Callback-Funktion auf, sobald der Ball mit dem Schläger kollidiert.
In diesem Fall soll der Punktestand erhöht werden. Das wird mit einer sehr einfachen anonymen Prozedur erledigt:
<source lang="javascript">
function(){ l_score.value++; }
</source>
Diese Prozedur erhöht bei jedem Aufruf im Text-Feld „<code>score</code>“ den Wert „<code>value</code>“ um eins.
Sobald ein neues Spiel gestartet wird, wird dieser Vert auf <code>0</code> gesetzt.

Die Prozedur „<code>collisionCanvasBall</code>“ informiert <code>minipong</code> mittels Callback, wenn der Ball die Bühne verlässt.
Als Callback-Funktion wird dieser Prozedur die Prozedur „<code>f_stop</code>“ (siehe unten) übergeben, um das Spiel zu beenden.

<source lang="javascript">
// Collision detection and handling.
function f_collision()
{
collisionBallPaddle(l_ball, l_paddle, function(){ l_score.value++; });
collisionCanvasBall(l_stage, l_ball, f_stop);
collisionStagePaddle(l_stage, l_paddle);
}
</source>

Ganz zu Beginn des Spiels, bei einem Abbruch durch den Spieler mittel Button-Klick und sobald der
Ball die Bühne verlässt wird das Spiel beendet. Dies ist die Aufgabe der Prozedur „<code>f_stop</code>“.

Sie hält die Model-Loop und Ball an und macht Ball und Schläger unsichtbar.
Dann ändert sie das Aussehen und das Verhalten des Start-Stopp-Buttons:
Sie weißt ihm das Label „<code>p_init.startGame</code>“ (<code>=== "Spiel starten"</code> gemäß <code>init.json</code>)
und die Prozedur „<code>p_start</code>“ zu. Das heißt, bei einem Klick auf diesen Button wird die Prozedur „<code>p_start</code>“
ausgeführt. Zu guter Letzt schreibt sie ins Info-Textfeld eine Nachricht, dass das Spiel beendet ist. Diese Nachricht
kann man überschreiben, indem man direkt im Anschluss an einen Aufruf von „<code>p_stop</code>“ eine
andere Nachricht ins Info-Textfeld schreibt. Dies geschieht direkt nachdem die Web-Anwendung gestartet wurde (siehe oben),

<source lang="javascript">
// Stop the game.
function f_stop()
{
l_model_loop.stop();
l_ball.stop();
l_ball.hide();
l_paddle.hide();

l_button.label = p_init.startGame;
l_button.onClick = f_start;

l_info.value = p_init.ballLost;
}
</source>

Wenn das Spiel angehalten wurde, kann man es mit einem Klick auf den Start-Stopp-Button starten.
Die zugehörige Start-Prozedur muss das Spiel zunächst zurücksetzen. Sie setzt den Score-Wert auf <code>0</code>,
löscht den Inhalt des Info-Textfeldes und setzt Schläger und Ball zurück an die Startpositionen.
Dann ändert sie das Aussehen und das Verhalten des Start-Stopp-Buttons:
Sie weißt ihm das Label „<code>p_init.stopGame</code>“ (<code>=== "Spiel beenden"</code> gemäß <code>init.json</code>)
und die Prozedur „<code>p_stop</code>“ zu. Das heißt, bei einem Klick auf diesen Button wird die Prozedur „<code>p_stop</code>“
ausgeführt und das Spiel sofort beendet.

Nun kann sie das eigentliche Spiel starten. Dazu macht sie Schläger und Ball sichtbar und startet dann den Ball und die Model-Loop.
Jetzt sind die Call-Backfunktionen der Kollisionsprozedur scharfgeschaltet. Das heißt, Kollisionen vom Schläger mit dem Ball
werden mit einem Puktgewinn belohnt (dieser wird durch die View-Loop auch sofort angezeigt).
Wenn der Ball die Bühne verlässt oder wenn der Benutzer den Start-Stopp-Button drückt, wird das Spiel beendet.
Der erspielte Score ist zu diesem Zeitpunkt noch sichtbar. Erst mit einem neuen Spielstart wird er wieder auf <code>0</code>
gesetzt.

<source lang="javascript">
// Start the game.
function f_start()
{
l_score.value = 0;
l_info.value = '';
l_ball.reset();
l_paddle.reset();

l_button.label = p_init.stopGame;
l_button.onClick = f_stop;

l_paddle.show();
l_ball.show();
l_ball.start();
l_model_loop.start();
}
</source>

Damit wurden alle Module vollständig erstellt und MiniPong sollte gespielt werden können.

==Quellen==
# {{Quelle|Braun, H. (2011): Webanimationen mit Canvas}}
# {{Quelle|Kowarschick, W.: Multimedia-Programmierung}}
[[Kategorie: HTML5-Tutorium: Canvas: MiniPong]][[Kategorie: HTML5-Beispiel]][[Kategorie:Kapitel:Multimedia-Programmierung:Beispiele]]

HTML5-Tutorium: JavaScript: Hello World 04

2016-10-13T11:43:41Z

Sautter: /* Automatische Generierung der Schnittstellenbeschreibung */

{{HTML5-Tutorium:JavaScript:HelloWorld:Menü}}
'''Musterlösung''': [https://glossar.hs-augsburg.de/beispiel/tutorium/es5/hello_world/WK_HelloWorld04/index.html <code>index.html</code>]
([https://glossar.hs-augsburg.de/beispiel/tutorium/es5/hello_world/WK_HelloWorld04/ SVN-Repository])
==Anwendungsfälle (Use Cases)==
Gegenüber dem [[HTML5-Tutorium:_JavaScript:_Hello_World_03|dritten Teil des Tutoriums]]
ändern sich die die Anwendungsfälle nicht. Die Anwendung leistet also genau dasselbe wie zuvor.

In diesem Teil des Tutoriums geht es darum, die Anwendung zu verbessern, so dass sie schneller ausgeliefert werden kann.
Außerdem wird die Entwicklungsarbeit mit Hilfe von Automatisierungstools erleichtert.

==Erstellen eines neuen Projektes==

Erstellen Sie ein neues Projekt „<code>HelloWorld04</code>“ und legen Sie dieses in Ihrem Repository ab.
Kopieren Sie anschließend alle Dateien aus dem dritten Teil des Tutoriums, passen Sie den Titel in der HTML-Datei an und committen Sie abermals.

==Erstellen einer Ordnerstruktur==

Grundsätzlich gilt auch bei der Programmierung: Ordnung ist das halbe Leben.

Web-Anwendungen werden sehr schnell sehr groß. Also sollte man sich eine geeignete Ordnerstruktur überlegen.
Üblicherweise legt man CSS-Dateien in einen Ordner namens „<code>css</code>“ und JavaScript-Dateien in einen Ordner namens
„<code>js</code>“ oder „<code>lib</code>“. Sollten es viele CSS- und/oder JavaScript-Dateien werden,
legt man im entsprechenden Ordner geeignete Unterordner an.

Legen Sie im Root-Verzeichnis Ihres Projektes folgende Ordner an:
* <code>web</code>: Der Inhalt dieses Ordners kommt später auf einen echten Web-Server.
* <code>src</code>: Dieser Ordner enthält die unkomprimierten CSS- und JavaScript-Dateien.
* <code>doc</code>: Dieser Ordner enthält die Projektdokumentation.
* <code>conf</code>: Dieser Ordner enthält Projektkonfigurationsdateien mit Ausnahme zweier zentraler Node.js-Dateien.
Legen Sie innerhalb der Ordner „<code>web</code>“ und „<code>src</code>“ jeweils zwei weitere Ordner an: „<code>css</code>“ sowie „<code>js</code>“ .

Öffnen Sie im Editorbereich die Datei „<code>index.html</code>“ und verschieben sie in den Ordner „<code>src</code>“.
Verschieben sie anschließend die Dateien „<code>main.css</code>“ und „<code>main.js</code>“
in die passenden Ordner „<code>src/css</code>“ bzw. „<code>src/js</code>“. Sie werden feststellen, dass die Verweise in den Link- und Script-Elementen der
Datei „<code>index.html</code>“ automatisch angepasst werden. Verschieben Sie nun die Datei „<code>index.html</code>“ in den Ordner „<code>web</code>“.

Das Ergebnis dieser Aktion ist, dass Ihre Web-Anwendung nicht mehr im Root-Verzeichnis des Projektes liegt, sondern (sauber strukturiert) in zwei Unterordnern.
Daher ist es möglich, im Root-Verzeichnis des Projektes weitere projektspezifische Ordner und Dateien anzulegen wie „<code>conf</code>“ und „<code>doc</code>“,
die später nicht auf den Web-Server, auf dem die Anwendung schließlich laufen soll, kopiert werden. Auch der Ordner „<code>src</code>“ existiert nur
in der Entwicklungsumgebung, lediglich der Inhalt des Web-Ordners ist für den Liveserver bestimmt.

==Laden der CSS- und der JavaScript-Dateien==

Eine Web-Anwendung funktioniert nur – wie Sie bereits erfahren haben –, wenn nicht nur die HTML-Datei, sondern auch die zugehörigen
CSS- und JavaScript-Dateien geladen werden. Allerdings gibt es dabei ein Problem: Die CSS- und JavaScript-Dateien werden im Laufe der
Zeit immer zahlreicher und/oder größer. Diese Dateien zu laden, dauert seine Zeit.

In der aktuellen Version der Web-Anwendung stehen diese Verweise auf diese Dateien im <code>head</code>-Bereich des Dokuments.
Dieser wird vollständig geladen, bevor der <code>body</code>-Bereich eingelesen wird. Das heißt aber, dass der Browser keine Inhalte des HTML-Dokuments
darstellen kann, solange er die JavaScript- und CSS-Dateien lädt. Wenn dies zu lange dauert, verliert der Besucher die Geduld und verlässt die Seite
vorzeitig.

Besser wäre es daher andersherum vorzugehen: Es wird zuerst der <code>body</code>-Bereich geladen und dann die JavaScript- und die CSS-Dateien.
Im Falle von JavaScript ist das durchaus sinnvoll, aber im Falle von CSS hat das den Effekt, dass der Browser keine Layout-Vorgaben erhalten hat,
wenn er mit dem [[Rendern]] der Seite beginnt. Also verwendet er die browserspezifischen Defaultwerte. Das heißt, die Seite sieht zunächst
ganz anders aus, als vom Designer geplant. Wenn dann die CSS-Dateien geladen wurden, wird die Seite erneut gerendert und verändert ihr Aussehen.
Auch das ist verwirrend und wirkt unprofessionell.

Was also machen?

===CSS-Dateien===
Für CSS-Dateien empfiehlt Google ernsthaft, die Link-Element ganz ans Ende der HTML-Datei zu stellen, also '''nach''' dem
schließenden <code>html</code>-Tag.
Damit das Problem mit dem falschen Layout nicht auftritt, sollen wichtige CSS-Befehle direkt – {{dh}} als CSS-Befehle innerhalb eines
<code>style</code>-Elements – in die HTML-Datei eingefügt
werden.<ref>{{Quelle|Google (Web)}}, Kapitel „CSS-Bereitstellung optimieren“, https://developers.google.com/speed/docs/insights/OptimizeCSSDelivery</ref>

Von beiden Vorschlägen rate ich dringend ab. Der erste Vorschlag ist nicht [[HTML]]-konform, ja noch nicht einmal [[SGML]]-konform. Es mag sein,
dass diverse Browser diese Syntax verstehen, korrekt ist sie trotzdem nicht. Der zweite Vorschlag hat zur Folge, dass Struktur (HTML) und Layout (CSS)
vermischt werden. Dies war einer der Kardinalfehler von frühen HTML-Versionen aus der Zeit, bevor es das CSS-Format gab. '''Tun Sie das nicht.'''

Gehen Sie so vor, wie es unter [[Multimedia-Programmierung: Best Practices#CSS|Multimedia-Programmierung: Best Practices]] beschrieben ist.

In unserer Anwendung haben wir bislang alles richtig gemacht, bis auf die fehlende automatische Komprimierung.
Diese wird weiter unten beschrieben.

===JavaScript-Dateien===

Für JavaScript-Dateien empfiehlt Google ebenfalls, diese nicht schon zu Beginn zu laden.<ref>{{Quelle|Google (Web)}}, Kapitel „CSS-Bereitstellung optimieren“, https://developers.google.com/speed/docs/insights/BlockingJS</ref> Dieser Vorschlag ist sehr sinnvoll.

Entfernen Sie das <code>script</code>-Element aus dem HTML-Header-Bereich und fügen Sie es vor dem schließenden <code>body</code>-Tag ein:

<source lang="html5">
...
<script type="text/javascript" src="../src/js/main.js"></script>
</body>
</source>

===Node.js===

Dieses Tutorium befasst sich zwar nicht mit der Erstellung von Node.js-Anwendungen, aber trotzdem benötigen wir
Node, da für die Komprimierung von Dateien und das automatische Erstellen von JavaScript-Dokumentationen
derartige Anwendungen zum Einsatz kommen.

Installieren Sie zunächst Node.js: <code>https://nodejs.org/en/</code>, Version 6.x. Diverse Versionen finden Sie unter https://nodejs.org/en/download/.
Achten Sie darauf, dass die Option „<code>Add to PATH</code>“ ausgewählt wurde.

Starten Sie WebStorm neu und öffnen Sie das Terminal, um zu testen, ob <code>node</code> funktioniert:

* Klick auf Icon in der linken unteren Ecke → <code>Terminal</code>
* Geben Sie Folgendes ins Terminal ein: <code>node --version</code>

Wenn Node.js korrekt installiert und der Pfad mit den <code>node</code>-Binaries in die Systemvariable <code>PATH</code> eingetragen wurde,
sollte die Versionsnummer von <code>node</code> ausgegeben werden.

Sie werden feststellen, das Node.js zum Großteil über Konsolbefehle gesteuert wird.
Zu Beginn mag das für eingefleischte [[Klickibunti]]-Fans ungewohnt sein, aber Sie werden sich schnell daran gewöhnen.

'''Tipp'''<br/>
Profis verwenden unter Windows lieber ein Terminal, dass eine [[Unix]]-[[Shell]] simuliert.
(Unter Linux und Mac OS X ist das nicht notwendig. Dort läuft sowieso schon eine UNIX-Shell.)

Installieren Sie „Git for Windows“ (https://git-for-windows.github.io/). In diesem Paket ist die „Git BASH“ enthalten.
Das ist eine Terminal-Anwendung, die eine Linux-Bash emuliert und zahlreiche nützliche Befehle wie „<code>which</code>“, „<code>[[vi]]</code>“ ( :-) ) etc. zur
Verfügung stellt.

Erstellen Sie im Wurzel-Verzeichnis Ihres Projektes einen Ordner namens „<code>node-modules</code>“.
Wenn die Frage „''Do you want to schedule the following directory for addition tu Subversion?''“
aufpoppt, antworten Sie unbedingt mit '''„<code>No</code>“''', anderenfalls werden Hunderte von Node.js-Dateien ins Repository geschrieben,
obwohl das überflüssig ist und '''sehr viel''' Zeit in Anspruch nimmt.
Anschließend führen Sie folgende Befehle aus:

* Rechtsklick auf den neu erstellten Ordner → <code>Subversion</code> → <code>Ignore</code> → <code>node-modules</code>

Öffnen Sie nun ein beliebiges Terminal (WebStorm-Terminal, Git Bash, Mac-OS-X-Terminal ...)
und geben Sie folgenden Befehl ein (npm = node package manager, https://www.npmjs.com/)

<source lang="bash">
npm install -g bower grunt-cli jsdoc ink-docstrap yuglify mincss coffee-script jshint
</source>

Damit werden die wichtigsten Node.js-Pakete ''global'' (Option „<code>-g</code>“) installiert, die wir im Folgenden noch benötigen, evtl. implizit.
Die globale Installation hat zur Folge, dass jedes Projekt auf diese Pakete zugreifen kann, Pakete also nicht mehrfach installiert werden.

* Rechtsklick im Dateibaum auf „<code>node-modules</code>“ → <code>Mark Directory as</code> → <code>excluded</code>
* Rechtsklick im Dateibaum auf „<code>doc</code>“ → <code>Mark Directory as</code> → <code>excluded</code>

Beide Ordner enthalten Dateien, die nicht von Ihnen stammen. Diese Dateien können Fehler und Hinweise enthalten,
veraltete (“deprecated”) Schnittstellen verwenden etc. (Oh ja, auch andere Programmierer machen Fehler. :-) )
Und wenn Sie diese beiden Ordner nicht als „<code>excluded markieren</code>“, prüft WebStorm bei jedem Commit die
darin enthaltenen Dateien und weist Sie auf jedes Problem hin. Das können so viele Probleme sein, dass Sie die
Probleme in Ihren eigenen Dateien vollkommen übersehen.

Nun müssen wir den Node-Paket-Manager „<code>npm</code>“ (https://docs.npmjs.com/) sowie Grunt (http://gruntjs.com/) initialisieren.
Grunt ist '''der''' “JavaScript Task Runner”, also ein Programm, das Aufgaben (''tasks'') wie {{zB}} das Komprimieren von Programmdateien
durchführt.

Die Initialisierung erfolgt durch die Bereitstellung von zwei Dateien „<code>package.json</code>“
und „<code>package.json</code>“ im Root-Verzeichnis der Web-Anwendung. Eine initiale Version der <code>package.json</code> könnten Sie theoretisch mit
<code>npm init</code> erstellen. Einfacher ist es jedoch, wenn Sie die beiden Dateien von Hand erstellen und folgenden Code einfügen:

'''<code>package.json</code>''' (https://docs.npmjs.com/files/package.json)
<source lang="bash">
{
"name": "hello_world_04",
"version": "1.0.0",
"description": "Hello World Tutorium",
"main": "gruntfile.js",
"directories": {
"doc": "./doc"
},
"dependencies": {},
"devDependencies": {
},
"scripts": {
"test": "echo \"Error: no test specified\" && exit 1"
},
"repository": {
"type": "svn",
"url": "https://glossar.hs-augsburg.de/kowa/tutorium/es5/hello_world/WK_HelloWorld04"
},
"author": "Wolfgang Kowarschick",
"license": "CC-BY-NC-SA-4.0"
}
</source>

Anmerkung: Diese Datei wird durch <code>npm</code> automatisch erstellt und geändert. Daher ist das Layout (welches mir nicht gefällt) vorgegeben.

Hier sollten Sie natürlich nicht meinen Repositorypfad und meinen Namen einfügen, sondern jeweils Ihren. Sie können außerdem die
Lizenz anpassen (https://spdx.org/licenses/), unter die Sie Ihre Software stellen, wenn Sie das möchten.

Die meisten Attribute sind selbsterklärend. Wichtig sind für uns vor allem zwei Attribute: „<code>main</code>“ und
„<code>devDependencies</code>“. Das erste enthält den Namen der Konfigurationsdatei von Grunt. Diese fehlt noch. Also: Legen Sie sie an
(und vergessen Sie nicht, Ihren Namen anstelle meines Namens einzufügen):

'''<code>gruntfile.js</code>'''
<source lang="javascript">
/**
* @author Wolfgang Kowarschick <kowa@hs-augsburg.de>
* @see http://gruntjs.com/getting-started
*
* Created on 2016/09/28.
*/

module.exports = function(grunt)
{
// Project configuration.
grunt.initConfig
({
pkg: grunt.file.readJSON('package.json'),
});

// Load the plugin that provides the "uglify" task.

// Default task(s).
};
</source>

Diese Datei ist noch ziemlich leer, aber das wird sich ändern.

Vorausschauend sollten Sie eine überflüssige WebStorm-Fehlerprüfung deaktivieren, da anderenfalls künftige Versionen
Versionen der Datei „<code>gruntfile.js</code>“ jedes Mal eine Fehlermeldung zur Folge haben, wenn die
Datei ins SVN-Repository geschrieben werden soll:

* <code>File</code> bzw. <code>WebStorm</code> → <code>Settings</code> bzw. <code>Preferences</code> → <code>Editor</code> → <code>Inspections</code>
* <code>JavaScript</code> aufklappen → <code>General</code> aufklappen → <code>Unsued JavaScript / ActionScript global symbol</code> deselektieren
* <code>OK</code>

Spannender ist in der Datei „<code>package.json</code>“ das Attribut „<code>devDependencies</code>“ (dev = developer).
Diese enthält eine Liste von von NodeJS-Paketen, die für die Entwicklung der Web-Anwendung benötigt werden.
Fügen wir einmal das Paket „<code>ink-docstrap</code>“ in diese Liste ein.
(Diese Pakte wird nachfolgend für die Erstellung der JavaScript-Dokumentation mittels JSDoc verwendet. Es enthält ein Theme, welches deutlich schöner ist als das Standard-JSDoc-Theme.)

Führen Sie folgenden Befehl im WebStorm-Terminal (oder mittels eine beliebigen anderen Shell im Wurzelverzeichnis Ihrer Web-Anwendung) aus:

<source lang="bash">
npm install ink-docstrap --save-dev
</source>

Dies bewirkt zweierlei:

# Das Node.js-Paket „<code> ink-docstrap</code>“ sowie diverse weitere Node.js-Pakete, die diese Paket benötigt, werden einem Projektordner namens „<code>node_modules</code>“ abgelegt.
# Das Name und die Versionsnummer des Paketes werden in das Attribut „<code>devDependencies</code>“ in der Datei „<code>package.json</code>“ eingefügt (wegen der Option „<code>--save-dev</code>“).

Nun steht Ihnen der Befehl
<source lang="bash">
npm update
</source>
zur Verfügung. Mit diesem können Sie die lokal gespeicherte Versionen der im Attribut „<code>devDependencies</code>“ aufgeführte Node.js-Pakete
jederzeit auf die neueste Version aktualisieren. Sie können ein Paket auch löschen und dann mittels <code>npm update</code> (https://docs.npmjs.com/cli/update) wieder herstellen.
Versuchen Sie es:

<source lang="bash">
npm remove ink-docstrap
npm list
</source>

Jetzt ist der Ordner „<code>node_modules</code>“ wieder leer.

<source lang="bash">
npm update
npm list
</source>

Und jetzt enthält der wieder „<code>ink-docstrap</code>“ sowie andere dafür notwendige Pakete.

Sie können auch überprüfen, ob Sie in Ihrem Projekt irgendwelche veralteten Pakete benutzen (https://docs.npmjs.com/cli/outdated):
<source lang="bash">
npm outdated
</source>

Kein Ergebnis ist hier ein gutes Ergebnis!

Und natürlich funktioniert das Ganze auch für global gespeicherte Pakete:

<source lang="bash">
npm -g outdated
npm -g list
</source>

Allerdings muss man veraltete globale Pakete erneut installieren. Zum Beispiel muss <code>npm</code>
relativ häufig aktualisiert werden (sobald „<code>npm -g outdated</code>“ das Paket als veraltet meldet):

<source lang="bash">
npm install -g npm
</source>

==Automatische Generierung der Schnittstellenbeschreibung==

Installieren Sie zunächst JSDoc:

* Öffnen Sie das WebStorm-Terminal.
* <code>npm install -g jsdoc</code> (installiert JSDoc als Node.js-Anwendung; das haben Sie eigentlich schon gemacht, aber das macht nix :-) )
* <code>npm install ink-docstrap</code> (installiert ein JSDoc-Theme namens „<code>docstrap</code>“ ([https://docstrap.github.io/docstrap/]); das haben Sie auch schon gemacht, aber das macht auch nix.)

Übrigens: Es gibt auch noch andere Themes für JSDoc.

Erstellen Sie im Projektordner „<code>conf</code>“ eine JSON-Datei namens „<code>jsdoc.json</code>“.
Fügen Sie in diese Datei folgenden Code ein:

<source lang="javascript">
{
"tags":
{
"allowUnknownTags": true
},
"source":
{
"include": ["./src/js"],
"includePattern": ".+\\.js$",
"excludePattern": "doc"
},
"plugins":
[],
"templates":
{
"systemName": "WK_HelloWorld04",
"footer": "",
"copyright": "Copyright © 2016 by Wolfgang Kowarschick, License <a href=\"https://creativecommons.org/licenses/by-nc-sa/4.0/\">CC-BY-NC-SA-4.0</a>",",
"navType": "vertical",
"theme": "cerulean",
"linenums": true,
"cleverLinks": false,
"monospaceLinks": true,
"collapseSymbols": true,
"inverseNav": false
},
"opts":
{
"template": "node_modules/ink-docstrap/template",
"encoding": "utf8",
"destination": "doc/jsdoc",
"recurse": true,
"private": true
}
}
</source>

Ersetzen Sie im Attribut „<code>footer</code>“ meinen Namen durch Ihren, denn es ist Ihr Projekt, nicht meines. :-)

In dieser Datei wird festgelegt, wie die HTML-Dokumentation des Codes, die JSDoc erstellt, aussehen soll.
Insbesondere ist das Template angegeben, das zur Erstellung dieser HTML-Dokumente verwendet werden soll.
Es handelt sich um „<code>docstrap</code>“, welches wir zuvor heruntergeladen haben. Von der
Projektroot aus gesehen, befinden sich die Template-Dateien im Ordner
„<code>node_modules/ink-docstrap/template</code>“.

Weitere Konfigurationsparameter werden unter http://usejsdoc.org/about-configuring-jsdoc.html beschrieben.

Sie können nun eine Dokumentation für Ihr Projekt erstellen:

* Öffnen Sie das WebStorm-Terminal.
* <code>jsdoc -c conf/jsdoc.json</code>

Nach kurzer Zeit sollte der Ordner „<code>doc/jsdoc</code>“ erstellt und mit Inhalten gefüllt worden sein.
Sehen Sie sich die Datei „<code>doc/jsdoc/index.html</code>“ im Browser an. Diese enthält nicht viel,
außer einem Drop-Down-Menü „<code>global</code>“, in dem die drei von Ihnen erstellen globalen Funktionen
„<code>greet</code>“, „<code>greet_on_enter</code>“ und „<code>init</code>“ enthalten sind.
Klicken Sie auf eine dieser Funktionen.

===Globale Speicherung der JSDoc-Templates===

Wenn Sie „<code>ink-docstrap</code>“ nicht mittels
<source lang="bash">npm install ink-docstrap</source>
sondern global mittels
<source lang="bash">npm install -g ink-docstrap</source>
installieren (so wie Sie das auch schon bereits getan haben), werden die Template-Dateien nicht im Projektordner, sondern im globalen <code>npm</code>-Ordner abgelegt.
Das hat den Vorteil, dass Sie dieses Template für viele Projekte einsetzen können und es nicht bei jedem Projekt separat speichern müssen.
Der Nachteil ist, dass in der Datei „<code>conf/jsdoc.json</code>“ den absoluten Pfad des globalen Ordners angeben müssen.
Dieser Pfad sieht auf jedem Rechner anders aus. Bei mir lautet er beispielsweise:
<source lang="bash">c:/Users/kowa/AppData/Roaming/npm/node_modules/ink-docstrap/template</source>

Das heißt, wenn man im Team an einem Projekt arbeitet, müsste man für jedes Teammitglied eine eigene
JSDoc-Konfigurationsdatei anlegen, was nicht wirklich schön, aber doch machbar ist.

In der [https://glossar.hs-augsburg.de/beispiel/tutorium/es5/hello_world/WK_HelloWorld04/ Musterlösung] verwende ich die lokale Version „<code>docstrap</code>“
(es gibt allerdings auch eine Datei namens „<code>conf/jsdoc_wk.json</code>“, die speziell für meinen Rechner erstellt wurde).
Die lokale Version von „<code>docstrap</code>“ ist allerdings nicht im Repository enthalten. Nachdem Sie die Musterlösung auf Ihren Rechner kopiert haben
(vergessen, wie's geht? → [[HTML5-Tutorium:_JavaScript:_Hello_World_01#Projekte_aus_einem_Subversion-Repository_laden|HTML5-Tutorium: JavaScript: Hello World 04]]),
müssen Sie im WebStorm-Terminal der Musterlösung noch folgenden Befehl ausführe:

<source lang="bash">
npm update
</source>

Und schon sollten Sie die Dokumentation wie gewohnt erstellen können.

Sobald Sie „<code>grunt</code>“ konfiguriert haben, sollte „<code>conf/jsdoc.json</code>“ auch in Ihrem Projekt fehlende Node.js-PAkete nachinstallieren.

===Erstellung der JSDoc-Dokumentation mittels Klickibunti===

Falls Sie die Dokumentation nicht immer über das Terminal erstellen möchten, können Sie
in WebStorm einen neuen Menüeintrag erstellen, über den Sie die Erzeugung der HTML-Dokumentation starten können.

Sie müssen dazu den Pfad ermitteln, unter dem Ihre <code>jsdoc</code>-Datei zu finden ist.
Unter Unix (Mac OS X, Linux, FreeBSD ...) lautet der Befehl, den Sie in ein Terminal eingeben müssen:
<source lang="bash">
which jsdoc
</source>
Unter '''Windows''' funktioniert dieser Befehl nur in der '''Git BASH'''.
Außerdem müssen Sie unter Windows den Bash-Pfad modifizieren, damit auch Windows etwas damit anfangen kann.
Bei mir gibt dieser Befehl Folgendes aus:
<source lang="bash">
/c/Users/kowa/AppData/Roaming/npm/jsdoc
</source>
Um <code>jsdoc</code> in WebStorm aufrufen zu können, müssen Sie in diesem Pfad „<code>/c</code>“ durch
„<code>c:</code>“ und „<code>jsdoc</code>“ durch „<code>jsdoc.cmd</code>“ ersetzen.
(Mac-User brauchen nichts zu ändern. :-) )

Erstellen Sie nun den neuen WebStorm-Menü-Eintrag:

* <code>File</code> → <code>Settings</code> → <code>Tools</code> → <code>External Tools</code>
* Klick auf das Plus-Icon
** <code>Name</code>: <code>JSDoc</code>
** <code>Group</code>: <code>Documentation</code>
** <code>Description</code>: <code>Generates JavaScript documentation</code>
** Hacken bei allen Optionen (<code>Options</code>)
** Hacken bei allen Show-in-Optionen (<code>Show i</code>) mit Ausnahme von „<code>Search results</code>“
* <code>Name</code>: <code>c:/Users/kowa/AppData/Roaming/npm/jsdoc.cmd</code> (hier kommt Ihr zuvor ermittelter Pfad hinein)
* <code>Name</code>: <code>-c $ProjectFileDir$/conf/jsdoc.json</code>
* <code>Name</code>: <code>$ProjectFileDir$</code>
* <code>OK</code>
* <code>OK</code>

Nun finden Sie an mehreren Stellen in WebStorm einen neuens Menüpunkt <code>Documentation</code> mit einem Unterpunkt <code>JSDoc</code>:

* Hauptmenü : <code>Tools</code> → <code>Documentation</code> → <code>JSDoc</code>
* Rechtsklick auf Datei im Projekt-Dateibaum → <code>Documentation</code> → <code>JSDoc</code>
* Rechtsklick auf Datei im Editor-Tab-Menü → <code>Documentation</code> → <code>JSDoc</code>

Wenn Sie auf einen dieser Unterpunkte „<code>JSDoc</code>“ klicken, erhalten Sie entweder eine Fehlermeldung ( :-( ) oder es wird eine neue Dokumentation erstellt
({{dh}}, Sie haben alles richtig gemacht :-) ).

Um sicher zu gehen, können Sie versuchsweise den Ordner „<code>doc</code>“ gemeinsam mit seinem gesamten Inhalt löschen und
<code>JSDoc</code> nochmals aufrufen.

===Sicherung im Repository===

Bevor Sie weitermachen: Haben Sie Ihre aktuelle Version von <code>Hello World 04</code> schon im Repository gesichert?

Bevor Sie die Projekt-Dateien per ''Commit'' ins Repository übertragen, sollten Sie überprüfen,
dass der Ordner „<code>node_modules</code>“ auf der sogenannten „Ignore List“ steht (und damit nicht
ins Repository eingespielt wird):

* <code>Files</code> bzw. <code>WebStorm</code> → <code>Settings</code> bzw. <code>Preferences</code> → <code>Ignored Files</code>
* Wenn in dieser Liste der Ordner „<code>node_modules</code>“ nicht aufgeführt wird, fügen Sie ihn mittels des Plus-Icons ein.

Sie sollten allerdings den Ordner „<code>doc</code>“ zu Ihrem
Repository hinzufügen:

* Klick auf „<code>doc</code>“ im Dateibaum → <code>Subversion</code> → <code>Add to VCS</code>

Nun können Sie Ihr Projekt committen.

==Automatische Komprimierung von CSS- und Javascript-Dateien==

Nun folgt die letzte Optimierung der Anwendung. Die von Ihnen erstellten CSS- und Javascript-Dateien
enthalten viele Leerzeichen, Kommentare, „sprechende“ anstelle von kurzen Variablenbezeichnern etc.
Das ist für Sie und alle anderen Entwickler von Vorteil. Für die Übertragung der Daten zu einem
Client (Browser) bedeutet das nur unnötiges Datenvolumen. Gerade für mobile Tarife mit Volumenbegrenzung
sollten so wenig Daten wie möglich übertragen werden.

Glücklicherweise gibt es Tools, die bestehende CSS- oder Javascript-Dateien komprimieren (meist sogar so, dass
sich die [[Semantik]] der Dateien nicht ändert; aber wie gesagt: Auch andere Programmierer machen hin und wieder Fehler).

Wir verwenden die Node.js-Tools „<code>cssmin</code>“ für CSS-Dateien (https://www.npmjs.com/package/cssmin) und
„<code>UglifyJS2</code>“ für JavaScript-Dateien (https://github.com/mishoo/UglifyJS2). Gesteuert werden diese “minimizer”
oder “minifier” mittels dem bereits installierten ''JavaScript Task Runner'' <code>grunt</code>“.

Die für das Minimieren mittels Grunt notwendige Pakete wurden ebenfalls bereits installiert:

<source lang="bash">
npm install grunt grunt-contrib-watch grunt-contrib-cssmin grunt-contrib-uglify --save-dev
</source>

Nun müssen die Aufgaben zu Komprimieren der JavaScript- und CSS-Dateien in die Konfigurationsdatei
eingefügt werden:

'''<code>gruntfile.js</code>'''
<source lang="javascript">
/**
* @author Wolfgang Kowarschick <kowa@hs-augsburg.de>
* @see http://gruntjs.com/getting-started
*
* Created on 2016/09/28.
*/

module.exports = function(grunt)
{
// Project configuration.
grunt.initConfig
({
pkg: grunt.file.readJSON('package.json'),

cssmin:
{ options: /* https://github.com/jakubpawlowicz/clean-css */
{ roundingPrecision: -1
},
minimize:
{ files:
{ 'web/css/main.css': ['src/css/main.css'],
}
}
},

uglify:
{ options:
{ mangle: true
},
minimize:
{ files:
{ 'web/js/main.js': ['src/js/main.js']
}
}
}

});

// Load the plugin that provides the "uglify" task.
grunt.loadNpmTasks('grunt-contrib-uglify');
grunt.loadNpmTasks('grunt-contrib-cssmin');

// Default task(s).
grunt.registerTask('default', ['uglify', 'cssmin']);
};
</source>

Die Funktion „<code>grunt.initConfig</code>“ aufgerufen und es wird ihr ein [[JavaScript-Objekt]] übergeben.
Im Attribut „<code>pkg</code>“ wird grund der Inhalt der Datei „<code>package.json</code>“ übergeben, damit Grunt ermitteln kann, welche Pakete verfügbar sind.
Die beiden anderen Attribute „<code>cssmin</code>“ und „<code>uglify</code>“ (deren Namen frei wählbar sind), werden die beiden Minifier konfiguriert.

In beiden Fällen können Optionen angegeben werden, wie {{zB}}, dass CSS-Maß-Angaben nicht gerundet werden sollen (es gibt Designer, die bestehen
beim Pixelmaß auf vier Nachkommastellen) oder dass geeignete JavaScript-Variablen-Namen „durch die Mangel gedreht“ (''mangle''), also durch kürze Namen ersetzt werden sollen.
Wichtiger ist jedoch die Angabe, welche Dateien überhaupt erstellt werden und was für Sourcedaten dafür verwendet werden solle.

Zu jeder Datei, die erstellt wird, kann man eine ganze Liste von Sourcedateien angeben. Das hat zur Folge, dass alle diese Sourcedateien nacheinander
komprimiert und dann in die Zieldatei eingefügt werden. Auch das ist eine Optimierung, um das Laden einer Web-Anwendung zu beschleunigen.
Eine große Datei wird per HTTP schneller übertragen als viele kleine. Künftig werden wir daher möglichst wenige komprimierte Dateien verwenden
und möglichst viele nicht-komprimierte JavaScript-Dateien in komprimierter Form nacheinander in nur eine einzige JavaScript-Datei einfügen.

Nach der Initialisierungsfunktion werden noch zwei weitere Funktionen aufgerufen. Mit <code>grunt.loadNpmTasks</code>
werden die Grunt-Plugins geladen, die die eigentliche Komprimierung vornehmen. Und mittels <code>grunt.loadNpmTasks</code>
wird festgelegt, welche Aufgaben standardmäßig ausgeführt werden, sobald der Befehl „<code>grunt</code>“ ausgeführt wird.

So, nun sollte alles funktionieren. Öffnen Sie das Web-Storm-Terminal und tippen Sie nacheinander folgende Befehle ein:

<source lang="bash">
grunt cssmin
grunt uglify
grunt
<source>

Sie werden feststellen, das jedes mal bestimmte Dateien in den Ordnern „<code>web/css</code>“ oder/und „<code>web/js</code>“
erstellt werden, die mit dem Namensbestandteil „<code>min</code>“ beginnen. Sehen Sie sich die erzeugten Dateien an.
Sie enthalten denselben Code wie die Original-Dateien, nur in komprimierter (und daher für den Menschen schwer lesbarer) Form.

Als nächstes muss die Datei „<code>index.html</code>“ angepasst werden. Diese lädt noch die unkomprimierten Dateien aus dem
Sourceverzeichnis. Künftig soll sie die komprimierten Dateien aus dem eigentlichen Web-Ordner laden:

<source lang="html5">
...
<link rel="stylesheet" type="text/css" href="css/main.css"/>
...
<script type="text/javascript" src="js/main.js"></script>
</source>

Ab sofort werden nicht mehr die Sourcedateien geladen, sondern die komprimierten, durch die Minifier erstellten Dateien.
Das heißt aber für uns, dass wir bei jeder Änderung an den Sourcedateien den Befehl „<code>grunt</code>“
ausführen müssen, um die Aktualisierungen in die komprimierten Versionen der JavaScript bzw. CSS-Dateien zu übertragen.

Das ist lästig und geht besser.

==Automatische Aktualisierung der komprimierten Dateien==

Mit Hilfe des Node.js-Paketes „<code>grunt-contrib-watch</code>“ kann man beliebige Dateibäume überwachen,
ob sich darin bestimmte Dateien ändern. In einem derartigen Fall kann man automatisch andere Grunt Tasks ausführen lassen.
Das lässt sich ausnutzen, um nach Änderungen einer CSS-Datei oder einer JavaScript-Datei die zugehörige komprimierte
Datei automatisch neu zu erstellen.

Öffnen Sie das WebStorm-Terminal und laden Sie das besagte Paket:

<source lang="bash">
npm install grunt-contrib-watch --save-dev
</source>

Erweitern Sie nun die Datei „<code>gruntfile.js</code>“ um einen Watch-Task:

<source lang="javascript">
watch:
{ css:
{ files: ['src/css/**/*.css'],
tasks: ['cssmin']
},
js:
{ files: ['src/js/**/*.js'],
tasks: ['uglify']
},
web:
{ files: ['web/**/*'],
options: { livereload: true,
spawn: false
}
}
}
</source>

Vergessen Sie nicht, das Plugin zu laden:
<source lang="javascript">
grunt.loadNpmTasks('grunt-contrib-watch');
</source>

Der Watch-Task überwacht drei verschiedene Ordner:

* Wann immer sich eine CSS-Datei im Ordner „<code>src/css</code>“ oder einem darin enthaltenen Unterordner ändert, wird der Task „<code>cssmin</code>“ ausgeführt.
* Wann immer sich eine JavaScript-Datei im Ordner „<code>src/js</code>“ oder einem darin enthaltenen Unterordner ändert, wird der Task „<code>uglify</code>“ ausgeführt.
* Wann immer sich irgendeine Datei im Web-Ordner ändert, wird eine <code>livereload</code>-Nachricht (http://livereload.com/) an einen lokalen Node-Server mit der Portnummer 35729 geschickt. (Keine Angst: Sie brauchen diesen Server nicht zu starten oder zu stoppen.)

Damit kann man Browser anweisen, die HTML-Dateien neu zu laden, wann immer sich etwas ändert.
Dies erfolgt entweder mit speziellen Browser-Plugins (http://livereload.com/extensions/) oder mit einem kleinen JavaScript-Hack:
Fügen Sie ans Ende der Datei „<code>main.js</code>“ folgenden Code ein:

<source lang="javascript">
// Enable live reloading for the WebStorm web server.
if (location.port === '63342') // WebStorm server port
{
var l_script = document.createElement('script');
l_script.src = 'http://'+(location.host||'localhost').split(':')[0]+':35729/livereload.js';
document.body.appendChild(l_script);
}
</source>

Dieser Code sorgt dafür, dass in eine HTML-Datei, die die Datei „<code>main.js</code>“ einbindet,
ein zusätzliches <code>script</code>-Element
<source lang="html5">
<script src="http://localhost:35729/livereload.js></script>
</source>
erstellt und in jede HTML-Datei eingefügt wird, die von einem WebStorm-Test-Server ausgeliefert wird.
(Der URI kann anstelle des Servernamens „<code>localhost</code>“ auf den echten Namen des Entwicklungsrechners enthalten, sofern
der Entwicklungsrechner einen derartigen Namen hat.)

Unter Port 35729 wird auf dem Entwicklungsrechner von <code>grunt-contrib-watch</code> der bereits erwähnte Livereload-Server gestartet und
die JavaScript-Datei „<code>livereload.js</code>“ zur Verfügung gestellt. Wenn man diese Datei in seine HTML-Datei einbindet,
aktualisiert sich die HTML-Datei fortan automatisch, sobald <code>grunt-contrib-watch</code> eine Änderung, wie {{zB}}
die Aktualisierung einer CSS-Datei, einer JavaScript-Datei, der HTML-Datei selbst oder einer anderen Datei, die von der HTML-Datei eingebunden wird,
meldet.

Allerdings wäre es falsch, <code>livereload.js</code> auf einem Live-Server ohne Testumgebung einzubinden. Dort läuft der Livereload-Server überhaupt nicht.
Daher wird zunächst ermittelt, über welchen Port die aktuelle HTML-Datei von Server ausgeliefert wurde.
Üblicherweise ist dies 80, 443, 8080, 8888 oder 8443. Andere Ports werden selten verwendet.
Der Port 63342 wird mit fast absoluter Sicherheit nicht von irgendeinem realen Server verwendet. Daher verwendet ihn WebStorm.
Und daher kann mit dem Test <code>if (location.port == 63342)</code> ermittelt werden, ob die aktuelle HTML-Datei von einem WebStorm-Server
ausgeliefert wurde oder von einem anderen Server. (Die globale JavaScript-Variable „<code>location</code>“ enthält den URI, über den die HTML-Datei
vom Browser geladen wurde.)

Nun ist es an der Zeit, den <code>grunt-contrib-watch</code> zu testen. Öffnen Sie „<code>index.html</code>“ im Browser
(Rechtsklick auf <code>index.html</code> → <code>Run 'index.html'</code>) und tippen Sie dann
<source lang="bash">
grunt watch
</source>
ins WebStorm-Terminal.
Ändern Sie nun einen Eintrag in der Datei „<code>main.css</code>“ ({{zB}} <code>font-family: "Comic Sans MS";</code> :-) ).
Wenn Sie diese Änderungen speichern (Strg-S, Apfel-S), sollten Sie zweierlei Reaktionen bemerken.
Zum einem wird ins Terminal die Meldung
<source lang="bash">
>> File "web/css/main.css" changed.
</source>
geschrieben und zum anderen ändert sich das Layout der HTML-Datei im Browser, da die aktualisierte CSS-Datei
automatisch vom Browser nachgeladen wurde.

Wenn Sie die Designsünde „Comic Sans MS“ rückgängig machen, ändert sich die Datei kurz darauf auch im Browser wieder.

Das ist schon ziemlich „cool“, hat aber noch einen Schönheitsfehler: Das WebStorm-Terminal kann nicht anderweitig genutzt werden, solange
der Grunt-Watcher läuft. Um dieses Problem zu beheben, wird ein WebStorm-Startup-Task definiert, der den Watcher bei jedem
Programmstart von WebStorm automatisch in einem eigenständigen [[Task]] startet. Der Watcher läuft dann, solange WebStorm geöffnet ist.
Für seine Ausgaben steht im ein eigenes Ausgabefenster zur Verfügung. Was will man mehr?

* <code>File</code> → <code>Settings</code> → <code>Tools</code> → <code>Startup Tasks</code> → <code></code>
* Klick auf grünes Plus-Icon → <code>Add New Configuration</code> → <code>Grunt.js</code>
** Name: <code>Watch</code>
** Gruntfile: <code>.../HelloWorld04/gruntfile.js</code> (sollte bereits korrekt eingetragen sein)
** Tasks: <code>watch</code>
** Der Node-Interpreter und das Node.js-Paket <code>grunt-cli</code> sollten ebenfalls bereits korrekt eingetragen sein.
* <code>OK</code> (Unter „<code>Run configuration</code>“ sollte jetzt „<code>Watch</code>“ stehen.)
* <code>OK</code>

Wenn Sie nun WebStorm neu starten, sollte und der Menüzeile am unteren Fensterrand ein Tabulator mit dem Namen „<code>Run</code>“ vorhanden sein.
Wenn Sie das zugehörige Fenster öffnen sollte dort Folgendes stehen:

<source lang="bash">
grunt watch
Running "watch" task
Waiting...
</source>

Sobald Sie irgendeine Änderung an eine <code>web</code>- oder <code>src</code>-Datei der Web-App vornehmen, werden alle im Watcher definierten Aktionen
(automatische Komprimierung bzw. Neuladen des HTML-Datei im Browser) automatisch ausgeführt. Der Watcher läuft solange, bis Sie WebStorm beenden.
Es erfolgt dabei sogar noch eine Sicherheitsabfrage, on Sie den Prozess „<code>Watch</code>“ beenden wollen.


==JSHint==

Ein weiteres sehr interessantes Tool, das den JavaScript-Entwickler unterstützt, ist JSHint (http://jshint.com/).
JSHint analysiert vorhandenen JavaScript-Code und weist auf Fehler und Strukturprobleme hin.

Installieren Sie zunächst die zugehörigen Node.js-Pakete:

<source lang="bash">
npm install grunt-contrib-jshint jshint-stylish --save-dev
</source>

Anschließend fügen Sie einen JSHit-Task in die Datei „<code>gruntfile.js</code>“ ein.

<source lang="javascript">
jshint:
{
all: ['gruntfile.js', 'src/**/*.js'],

options:
{
esversion: 5,
eqeqeq: true,
eqnull: true,
browser: true,
reporter: require('jshint-stylish')
}
}
</source>

Nun können alle vom Entwickler erstellten JavaScript-Dateien analysiert werden. Geben Sie dazu im
WebStorm-Terminal einfach folgenden Befehl ein:

<source lang="bash">
grunt jshint
</source>

Gut ist es, wenn JSHint mit der Meldung <code>v No problems</code> antwortet.
Ansonsten sollten Sie in Ihrem Code die von JSHint gemeldeten Probleme beheben.

Machen Sie ruhig mal die Probe auf's Exempel: Ersetzen Sie „<code>===</code>“
in der Datei „<code>main.js</code>“ durch „<code>==</code>“ und lassen Sie
danach JSHint laufen. Dann sollte JSHint Folgendes melden:

<source lang="bash">
Expected '===' and instead saw '=='.
</source>

Damit wird ausgedrückt, dass ein nicht-strikter Gleichheitstest verwendet wurde,
aber ein strikter Gleichheitstest verwendet werden sollte. Der Grund ist, dass
nicht-strikte Fehlertests manchmal subtile Fehler zur Folge haben, die
nur sehr schwer zu entdecken sind.

JSHint kennt zahlreiche Optionen, die festlegen, welche Fehler und Probleme gemeldet
werden sollen und welche nicht: http://jshint.com/docs/options/.
Hier muss jeder Programmierer seinen eigenen Stil finden.

Folgende Optionen wurden im obigen Beispiel verwendet:

<dl>
</dt><code>esversion: 5</code></dt>
<dd>Des sollen die Regeln von [[EcmaScript 5]] beachtet werden.</dd>
</dt><code>eqeqeq: true</code></dt>
<dd>Es sollt stets ein strikter Gleichheitstest verwendet werden.</dd>
</dt><code>eqnull</code></dt>
<dd>Der nicht-strikte Gleichheitstest <code>... == null</code> ist allerdings erlaubt.
</dd>
</dt><code>browser: true</code></dt>
<dd>Globale Variable sollte man eigentlich grundsätzlich nicht verwenden.
Mit dieser Option werden für die globalen Variablen, die die Browser bereitgestellt werden
(<code>document</code>, <code>window</code>, <code>console</code> etc) Ausnahmen definiert.</dd>
</dl>

'''Anmerkung''': Wäre der nicht-strikte Gleichheitstest auf „<code>null</code>“ nicht erlaubt, müsste man in viele Fällen
„<code>... === null || ...=== undefined</code>“ schreiben. Geben Sie folgende Befehle einfach mal
in die Konsole Ihres Web-Browsers ein (Firefox: Strg-Shift-K, Opera und Chrome: Strg-Shift-I -> <code>Console</code>):

<source lang="javascript">
var a;
var b = null;

// Strikte Gleichheitstests
console.log(a === null); /* -> false */
console.log(a === undefined); /* -> true */
console.log(b === null); /* -> true */
console.log(b === undefined); /* -> false */
console.log(a === null || a === undefined); /* -> true */
console.log(b === null || b === undefined); /* -> true */

// Nicht-strikte Gleichheitstests
console.log(a == null); /* -> true */
console.log(a == undefined); /* -> true */
console.log(b == null); /* -> true */
console.log(b == undefined); /* -> true */
</source>

Zum Abschluss können Sie entweder einen WebStorm-Menü-Eintrag hinzufügen, um den JSHint jederzeit per Klickibunti starten zu können.
Oder Sie fügen gleich „<code>jslint</code>“ in die Watch-Liste ein, damit jede Änderung sofort analysiert und Fehler sofort angezeigt werden:

'''<code>gruntfile.js</code>'''
<source lang="javascript">
watch:
{ ...
js:
{ files: ['src/js/**/*.js'],
tasks: ['uglify', 'jshint']
},
...
}
</source>

Allerdings kann JSHint manchmal nerven. :-) Dagegen helfen dann spezielle Kommentare im JavaScript-Code, die
JSHint anweisen für die Prüfung des nachfolgenden Codes spezielle Optionen zu benutzen, die dann {{iAllg}}
eine etwas weniger strenge Überprüfung des Codes zur Folge haben (http://jshint.com/docs/).

==Quellen==
<references/>
<ol>
<li value="3"> {{Quelle|Kowarschick, W.: Multimedia-Programmierung}}</li>
</ol>
<noinclude>[[Kategorie: HTML5-Tutorium: JavaScript: Hello World]][[Kategorie: HTML5-Beispiel]][[Kategorie:Kapitel:Multimedia-Programmierung:Beispiele]]</noinclude>