|
|
| Zeile 1: |
Zeile 1: |
| {{HTML5-Tutorium:JavaScript:HelloWorld:Menü}} | | {{HTML5-Tutorium:JavaScript:HelloWorld:Menü}} |
|
| |
|
| Zur Erstellung von Web-Anwendungen kann [[WebStorm]] eingesetz werden.. | | Zur Erstellung von Web-Anwendungen kann [[WebStorm]] eingesetzt werden. |
| Zunächst müssen Sie diese IDE installieren und konfigurieren. Es handelt sich um eine kommerzielle | | Zunächst müssen Sie diese IDE installieren und konfigurieren. Es handelt sich um eine kommerzielle |
| Software, aber als Student erhalten Sie eine kostenlose Lizenz. | | Software, aber als Student erhalten Sie eine kostenlose Lizenz. |
| Zeile 75: |
Zeile 75: |
| suchen dort via Lupe nach „<code>Markdown support</code>“ und klicken anschließend auf <code>Search in Repositories</code>. | | suchen dort via Lupe nach „<code>Markdown support</code>“ und klicken anschließend auf <code>Search in Repositories</code>. |
| Dort erscheint dann ein Plugin namens „<code>Markdown support</code>“. Installieren Sie dieses und starten WebStorm danach neu. | | Dort erscheint dann ein Plugin namens „<code>Markdown support</code>“. Installieren Sie dieses und starten WebStorm danach neu. |
|
| |
| ==Node.js==
| |
|
| |
| Dieses Tutorium befasst sich zwar nicht mit der Erstellung von [[Node.js-Server]]-Anwendungen, aber trotzdem benötigen wir
| |
| [[Node.js]], da für die Komprimierung von Dateien und das automatische Erstellen von JavaScript-Dokumentationen
| |
| Tools zum Einsatz kommen, die mit Hilfe von Node entwickelt wurden.
| |
|
| |
| Installieren Sie zunächst Node.js: <code>https://nodejs.org/dist/latest/</code>, Version 7.x. Diverse Versionen finden Sie unter https://nodejs.org/dist/latest/.
| |
| 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 → Klick auf <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 Terminal-Befehle 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, das 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.
| |
|
| |
| {{TBD}}
| |
| Ö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 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.
| |
| Die globale Installation hat zur Folge, dass jedes Projekt auf diese Pakete zugreifen kann, Pakete also nicht mehrfach installiert werden müssen.
| |
|
| |
| Als nächstes initialisieren Sie den Node-Paket-Manager „<code>npm</code>“ (https://docs.npmjs.com/) sowie Grunt (http://gruntjs.com/) .
| |
| 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>gruntfile.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 tutorial",
| |
| "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_HelloWorld05"
| |
| },
| |
| "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, unter die Sie Ihre Software stellen, anpassen (https://spdx.org/licenses/), 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:
| |
|
| |
| '''<code>gruntfile.js</code>'''
| |
| <source lang="javascript">
| |
| 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>
| |
|
| |
| ==Ausschließen diverser Dateien von automatischer Speicherung und/oder Überprüfung==
| |
|
| |
| Sie sollten unbedingt verhindern das Node.js-Modulateien ins Repository geschrieben werden. Da sit, wie Se zuvor gesehen haben,
| |
| überflüssig und nimmt '''sehr viel''' Zeit in Anspruch, da es sich um Hunderte von Dateien handelt:
| |
|
| |
| * Rechtsklick im Dateibaum auf <code>node_modules</code> → <code>Subversion</code> → <code>Ignore</code> → <code>node_modules</code>
| |
| * Sollte der vorangegangene Schritt schief gegangen sein (WebStorms Subversion-Tools sind in dieser Hinsicht ziemlich schlecht), müssen Sie den letzten Schritt gegebenenfalls mit einem anderen Tool bewerkstelligen. Unter Windows ist Tortoise dafür recht gut geeignet.
| |
|
| |
| Außerdem sollten Sie die automatische Überprüfung auf Fehler für alle Ordner ausschalten, die nicht von Ihnen stammen:
| |
|
| |
| * 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.
| |
|
| |
| ==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>copyright</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>sayHello</code>“, „<code>sayHelloOnEnter</code>“ und „<code>init</code>“ enthalten sind.
| |
| Klicken Sie auf eine dieser Funktionen.
| |
|
| |
| ===Vermeidung globaler Funktionen===
| |
|
| |
| Die Verwendung von globalen Variablen oder Funktionen in JavaScript ist extrem gefährlich.
| |
| Wenn man eine JavaScript-Datei verwendet, in der
| |
| globale Funktionen enthalten sind, die zufälligerweise genauso heißen, wie
| |
| globale Funktionen in der eigenen JavaScript-Datei, kann man nicht beide
| |
| Dateien laden, da globale Funktionen, die in der ersten Datei enthalten sind,
| |
| durch globale Funktionen der zweiten Datei überschrieben werden.
| |
|
| |
| Daher ist es besser, Funktionen wie „<code>sayHello</code>“, „<code>sayHelloOnEnter</code>“ und „<code>init</code>“
| |
| in ein JavaScript-Objekt einzufügen. In unseren Fall könnte man beispielsweise ein
| |
| JavaScript-Objekt „<code>main</code>“ erzeugen, dass diese drei Funktionen enthält.
| |
| Damit hat man nur noch eine globale Variable (<code>main</code>) und die Gefahr
| |
| einer zufälligen Namenskollision bei Verwendung mehrerer JavaScript-Dateien ist geringer.
| |
|
| |
| Am besten ist es natürlich, auf globale Größen ganz zu verzichten. Dazu braucht man aber ein
| |
| Modul-System. Dieses ist für [[EcmaScript 6]] geplant ([https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Statements/import
| |
| <code>import</code>] und [https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Statements/export <code>export</code>]), wird
| |
| aber derzeit nur von wenigen Browsern unterstützt.
| |
|
| |
| Erserten Sie den Code in Ihrer Datei „<code>main.js</code>“ durch folgenden Code:
| |
|
| |
| <source lang="javascript">
| |
| /** @namespace main */
| |
| var
| |
| main =
| |
| {
| |
| /**
| |
| * Welcomes the user of the web app by displaying a welcome message
| |
| * that includes his name. The name is fetched from a text input field.
| |
| */
| |
| sayHello:
| |
| function()
| |
| {
| |
| document.getElementById('text_hello').innerHTML =
| |
| 'Hello, ' + document.getElementById("input_name").value + '!';
| |
| document.getElementById('section_form').classList.add('hidden');
| |
| document.getElementById('section_welcome').classList.remove('hidden');
| |
| },
| |
|
| |
| /**
| |
| * An keyboard event observer. It tests whether the enter key has been pressed.
| |
| * If so, the sayHello method is activated. Default reactions of the browser are
| |
| * disabled.
| |
| * @param {KeyboardEvent} p_event - A standard JavaScript keyboard event object
| |
| * (https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent)
| |
| */
| |
| sayHelloOnEnter:
| |
| function(p_event)
| |
| {
| |
| if (p_event.code === 'Enter' || p_event.keyCode === 13)
| |
| {
| |
| p_event.preventDefault();
| |
| p_event.stopPropagation();
| |
| main.sayHello();
| |
| }
| |
| },
| |
|
| |
| /**
| |
| * Initializes the web app.
| |
| * Is to be called when the web app has been loaded completely.
| |
| */
| |
| init:
| |
| function()
| |
| {
| |
| document.getElementById('button_submit')
| |
| .addEventListener('click', main.sayHello);
| |
|
| |
| window.addEventListener('keydown', main.sayHelloOnEnter);
| |
| }
| |
| };
| |
|
| |
| // Call main.init, when you are ready with loading.
| |
| window.addEventListener('load', main.init);
| |
| </source>
| |
|
| |
| Mit dem JSDoc-Kommentar „<code>@namespace main</code>“
| |
| wird angezeigt, dass die globale Variable „<code>main</code>“
| |
| als „[[Namensraum]]“ fungiert. Das heißt, <code>main</code>
| |
| enthält diverse Funktionen und evtl. andere Elemente, die irgendeinen inneren
| |
| Zusammenhang haben.
| |
|
| |
| Wen Sie jetzt JSDoc erneut ausführen, beschreibt Ihre Dokumentation keine globale
| |
| Funktionen mehr, sondern einen Namensraum „<code>main</code>“, der die
| |
| Funktionen „<code>sayHello</code>“, „<code>sayHelloOnEnter</code>“ und „<code>init</code>“
| |
| enthält. Auf diese Funktionen kann mittels „<code>main.sayHello</code>“, „<code>main.sayHelloOnEnter</code>“
| |
| und „<code>main.init</code>“ zugegriffen werden.
| |
|
| |
| ===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>Program</code>: <code>c:/Users/kowa/AppData/Roaming/npm/jsdoc.cmd</code> (hier kommt Ihr zuvor ermittelter Pfad hinein)
| |
| * <code>Parameters</code>: <code>-c $ProjectFileDir$/conf/jsdoc.json</code>
| |
| * <code>Working directory</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 und um nicht mehr verwendete Dokumentationsdateien wie „<code>doc/jsdoc/global.html</code>“ zu entfernen, sollten Sie den Ordner „<code>doc/jsdoc</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 (vgl. http://gruntjs.com/getting-started):
| |
|
| |
| '''<code>gruntfile.js</code>'''
| |
| <source lang="javascript">
| |
| module.exports = function(grunt)
| |
| {
| |
| // Project configuration.
| |
| grunt.initConfig
| |
| ({
| |
| pkg: grunt.file.readJSON('package.json'),
| |
|
| |
| cssmin:
| |
| { options: /* https://github.com/jakubpawlowicz/clean-css */
| |
| { roundingPrecision: -1,
| |
| keepSpecialComments: 1
| |
| },
| |
| minimize:
| |
| { files:
| |
| { 'web/css/main.css': ['src/css/terminal.css', 'src/css/main.css']
| |
| }
| |
| }
| |
| },
| |
|
| |
| uglify:
| |
| { options: /* https://github.com/gruntjs/grunt-contrib-uglify */
| |
| { mangle: true,
| |
| preserveComments: function(p_node, p_comment)
| |
| { return /@license/.test(p_comment.value); }
| |
| },
| |
| minimize:
| |
| { files: { 'web/js/main.js': ['src/js/terminal.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.
| |
| <!-- „<code></code>“ npm install grunt-contrib-watch --save-dev-->
| |
|
| |
| ==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
| |
| in der Datei „<code>main.js</code>“ „<code>=</code><code>==</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 „
| |
| <source lang="javascript">
| |
| if (... === null || ...=== undefined)
| |
| </source>
| |
| schreiben. Geben Sie folgende Befehle einfach mal in die Konsole Ihres Web-Browsers ein
| |
| (Firefox: <code>Strg-Shift-K</code>, Opera und Chrome: <code>Strg-Shift-I</code> → <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/).
| |
|
| |
|
| |
|
| |
| [[Kategorie:Kapitel:Web-Programmierung]]
| |
| [[Kategorie:Web-Programmierung-HowTo]]
| |
| [[Kategorie:Praktikum:MMProg]]
| |
|
| |
|
| ==Quellen== | | ==Quellen== |
