Schneller Tipp: AMD Packages

ReneRubalcava

<\/HEAD>

<\/P>

<\/P>

Vielleicht bist du neu bei der ArcGIS API for JavaScript oder vielleicht auch ein erfahrener Nutzer, aber irgendwann hast du dich sicher schon intensiv mit AMD<\/A> und modularen JavaScript beschäftigt.<\/P>

<\/P>

Ich habe schon einige Beiträge darüber geschrieben, einer davon ist

Embrace your AMD modules<\/A>, sowie ein Beitrag zu custom builds<\/A>. Ich habe sogar ein Video aufgenommen über die Nutzung der Bower-Version der ArcGIS JS API<\/A>.<\/P>

<\/P>

Eine Frage taucht ziemlich oft auf, und zwar eine Frage zu packages.<\/P>

<\/P>

Was sind sie und warum sind sie wichtig?<\/H2><\/P>Keine Sorge, packages sind ein Konzept, das mich auch einmal verwirrt hat. Packages können als Namespaces betrachtet werden, ähnlich wie man sie in Java<\/A> oder einer anderen Sprache sieht.<\/P>

<\/P>

Lass uns ein paar Aussagen anhand der Standard-ES5-Syntax aufschlüsseln.<\/P>

<\/P>

define(["esri\/map"], function(map) {});<\/PRE><\/P>Hier fordern wir das map<\/EM>-Modul aus dem esri<\/EM>-package an. Die gesamte ArcGIS API for JavaScript befindet sich im esri<\/EM>-package. Es gibt weitere Abhängigkeiten von anderen packages wie dojo<\/EM> oder dojox<\/EM>.<\/P><\/P>Normalerweise musst du dir nicht allzu viele Gedanken über packages machen, wenn du eine einfache Anwendung erstellst. Wenn du das CDN der API verwendest, kennst du wahrscheinlich diesen 

kleinen Trick<\/A>, um deinen lokalen Code zu nutzen.<\/P>

<\/P>

Verwendung von packages<\/H2><\/P>Das ist alles schön und gut, aber wenn du die Bower-Version der API<\/A> nutzt und benutzerdefinierte lokale Builds machen möchtest, dann sind packages wichtig. Denn du musst dem Dojo-Build-System mitteilen, welche packages es kennen soll. Der einfachste Weg ist, das esri<\/EM>-package und seine Abhängigkeiten unter einem Quellordner abzulegen. Dein Anwendungscode sollte in einen app<\/EM>-Ordner kommen.<\/P><\/P>Das bedeutet, dass deine Anwendungsstruktur ungefähr so aussehen würde.<\/P><\/P>src\n  \u251c\u2500\u2500 app\n  \u251c\u2500\u2500 dgrid\n  \u251c\u2500\u2500 dijit\n  \u251c\u2500\u2500 dojo\n  \u251c\u2500\u2500 dojox\n  \u251c\u2500\u2500 dstore\n  \u251c\u2500\u2500 xstyle\n  \u251c\u2500\u2500 put-selector\n  \u251c\u2500\u2500 esri<\/PRE><\/P>Du kannst diesen Leitfaden<\/A> lesen, um herauszufinden, wie Bower in dein Quellverzeichnis installiert wird. Nun kannst du dem Dojo-Build-System in deinem Build-Profil mitteilen, welche packages es kennen soll.<\/P>

  packages: [\n    \/\/'app' ist ein Beispielpfad für deine Anwendung\n    \/\ setze dies entsprechend fest\n    'app',\n    'dijit',\n    'dojo',\n    'dojox',\n    'dstore',\n    'dgrid',\n    'xstyle',\n    'put-selector',\n    'esri'\n  ],<\/PRE><\/P>Du kannst hier ein 

Beispiel-Build-Profil sehen<\/A>. Wenn du weitere Bibliotheken hinzufügst, wie Bootstrap<\/EM> und jQuery<\/EM>, kannst du sie einfach zur Liste der packages hinzufügen.<\/P><\/P>Am Ende des Tages sind packages nichts anderes als eine Möglichkeit, deinen Code organisiert zu halten.<\/P>
Das ist aber noch nicht das Ende der Geschichte für packages<\.EM>. Es gibt weitere Details, die du lernen kannst, um dem Dojo-Build-System mitzuteilen, dass ein Ordner ein package ist und dass es sich um ein AMD package handelt. Es gibt sogar Möglichkeiten, Testverzeichnisse zu ignorieren, die sich möglicherweise in deinem package-Ordner befinden.
 
Diese Details werde ich beim nächsten Mal behandeln!<\.STRONG>
 

Für mehr geodev Tipps und Tricks, schau dir meinen Blog an: check out my blog.