nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Nutze deine AMD-Module

ReneRubalcava

<\/HEAD>

<\/P>

Eine Frage in den Foren<\/A> tauchte kürzlich auf, die ich vielleicht besser in Form eines Blogbeitrags erklären kann als in einer einzelnen Antwort. Wie migriere ich von legacy Dojo zu modernem Dojo AMD-Stil?<\/EM> Das ist eine berechtigte Frage, und eine, mit der ich mich schwergetan habe<\/A>, als Dojo 1.7 veröffentlicht wurde. Du kannst dich auf das Migrieren zu 3.0<\/A> in der Dokumentation beziehen, um eine Vorstellung von den Änderungen zu bekommen.<\/P>

<\/P>

Ich denke, mittlerweile wissen die Leute, dass dojo.declare jetzt ein Modul namens dojo\/_base\/_declare ist, aber wie man AMD-Teile verwendet, sorgt für einige Verwirrung.<\/P>

<\/P>

Ich denke, einige der Hürden bestehen einfach darin, sich mit AMD vertraut zu machen. Ich hatte anfangs einige Gehirnverdreh-Momente damit, da ich nicht sicher war, wann ich require<\/SPAN> oder wann ich define<\/SPAN> verwenden soll oder wie man mit Modulen arbeitet. Meine anfänglichen Schwierigkeiten lagen bei requirejs und ich hatte keinen Mentor, der mir wirklich helfen konnte, aber ich habe mich durch Dokumentationen und Google-Gruppen-Beiträge gekämpft, um es herauszufinden. Als Dojo 1.7 mit dem AMD-Loader veröffentlicht wurde, war ich besser vorbereitet.<\/P><\/P>Lass uns das auf seine einfachste Form herunterbrechen und was du in den meisten Beispielen auf der

ArcGIS Developers Seite<\/A> sehen wirst.<\/P>

require(["esri\/_map", "dojo\/_domReady!"], function(Map) { 
  var map = new Map("map", {
    center: [-118, 34.5],
    zoom: 8,
    basemap: "topo"
  });
});<\/PRE><\/P>Da ist die gefürchtete require<\/SPAN>-Methode. Wenn du jemals in C++\Java oder ähnlichen Sprachen gearbeitet hast, bist du vielleicht mit der main()<\/SPAN>-Funktion vertraut. Das ist die Funktion, die beim Start einer Anwendung ausgeführt wird, hier beginnt die Party<\/EM>. Die require<\/SPAN>-Methode ist die main-Funktion von AMD<\/STRONG>. Also irgendwo in den ArcGIS API for JavaScript Modulen, die über CDN heruntergeladen werden, wenn du das Skript-Tag zu deiner Seite hinzufügst, gibt es eine JavaScript-Datei namens map.js<\/SPAN> in einem Ordner namens esri<\/SPAN>, die so aussieht.<\/P><\/P>define(['dependency1', 'dependency2'], function(dependency1, dependency2) {
  var Map;
  \/*magische Einhorn-Sachen*\/
  return Map;
});<\/PRE><\/P>Die require<\/SPAN>-Methode sucht diese Datei und lädt sie asynchron in deine Anwendung. Wenn das Laden abgeschlossen ist, wird die Funktion in deiner Anwendung aufgerufen und das, was definiert, was eine Map ist (sehr existenziell<\/EM>), wird von der Funktion zurückgegeben. Beachte, dass dieses Modul eigene Abhängigkeiten hat und diese in der Funktion in der Reihenfolge geladen werden, in der sie angefordert werden. DAS IST WICHTIG. Die Reihenfolge ist entscheidend<\/EM>. Diese Abhängigkeiten können Funktionen oder Objekte sein oder vielleicht Strings. Unten ist ein Diagramm aus

meinem Buch<\/A>, das dir helfen könnte.<\/P>

<\/P>

In meinem Buch verwende ich eine Datei namens run.js<\/SPAN>, die die require<\/SPAN>-Methode verwendet und meine

dojoConfig<\/A> definiert sowie eine main.js<\/SPAN>, die tatsächlich mit der Arbeit beginnt. Das ist nur mein Stil, aber nicht der definitive Stil.<\/P><\/P>Manche Leute stolpern über die Verwendung von main.js<\/SPAN>, und ehrlich gesagt ging es mir am Anfang auch so. Ein guter Bezugspunkt ist das Advanced Modules<\/A>-Tutorial von Dojo. Ich zitiere den wichtigen Teil unter Konfigurieren des Loaders.<\/P>

main (optional, Standard = main.js😞) wird verwendet, um das korrekte Modul zu entdecken, das geladen werden soll, wenn jemand versucht, das Paket selbst zu require'n. Zum Beispiel würde beim Versuch "dojo" zu require'n tatsächlich die Datei "\/_js\/_dojo\/_main.js" geladen werden. Da wir diese Eigenschaft für das "my"-Paket überschrieben haben, würde beim Require'n von "my" tatsächlich "\/_js\/_my\/_app.js" geladen werden.Wenn wir versuchen würden "util" zu require'n, was kein definiertes Paket ist, würde der Loader versuchen "\/_js\/_util.js" zu laden. Du solltest immer alle deine Pakete in der Loader-Konfiguration definieren.

Hier ist ein Beispiel dafür, wie einer meiner dojoConfigs aussehen könnte – mein require-Einstiegspunkt.

var pathRX = new RegExp(\/2[^\\/]+$\/) 
 , locationPath = location.pathname.replace(pathRX, '');
require({
  packages: [{
    name: 'widgets',
    location: locationPath + 'js/widgets'
  }, {
    name: 'utils',
    location: locationPath + 'js/utils'
  }, {
    name: 'app',
    location: locationPath + 'js'
 }]
}, ['app']);

Im require-Aufruf ist der erste Parameter das dojoConfig-Objekt und der zweite Parameter die Abhängigkeit ['app'], dies ist mein Einstiegspunkt. Laut obiger Dokumentation wird standardmäßig bei Anforderung von ‘app’ nach ‘app/main.js’ gesucht.

Wenn dir das alles noch zu verwirrend ist, kannst du auch einfach ein globales dojoConfig-Objekt definieren, um deine Pakete zu konfigurieren und einen einfachen älteren require-Aufruf verwenden, um deine Anwendung zu starten. So etwas:

<body class="nihilo">
 <script>
    var pathRX = new RegExp(\/2[^\\/]+$\/) 
     , locationPath = location.pathname.replace(pathRX, '');
    var dojoConfig = {
      async: true,
      isDebug: true,
      packages: [
        { name: 'xstyle', location: locationPath + '/bower_components/xstyle' },
        { name: 'mayhem', location: locationPath + '/bower_components/mayhem/dist' },
        { name: 'app', location: locationPath + 'js' }
      ],
      tlmSiblingOfDojo: false
   } ;
&nbsp</script>
&nbsp<script>require(['app/start'], function() {})</script>
</body>

Hoffentlich klärt das einiges etwas auf.

Du kannst viel davon über die Dojo-Dokumentation lernen und besonders über das CDN Modules-Tutorial. Diese Seite behandelt einige Legacy-zu-modern Dojo-Themen ausführlich. Hier ist ein Migrationsleitfaden. Hier ist ein Legacy Dojo zu AMD Konverter, den du auch ausprobieren kannst. Ich habe ihn nie benutzt, aber es könnte ein guter Ausgangspunkt sein. Ich bezweifle, dass er mit allen Esri-Modulen zu 100 % funktioniert, aber einen Versuch wert.

Ich hoffe, das hilft dir etwas weiter, wenn du noch Schwierigkeiten hast bei der Migration von Legacy Dojo-Anwendungen zum modernen Dojo. Es kann etwas Zeit brauchen bis alles sitzt – aber es wird klappen. Für mehr geodev Tipps und Tricks schau mal auf meinen Blog unter meinem Blog.

Finde mehr Beiträge mit dem Tag

GeoDev Adventures

Kommentare

EvelynHernandez

Its useful for beginners trying to learn how to develop in JS. But it will be more useful if u put some simple examples about how to modularize ur apps properly, how to call functions from another js,etc.

TracySchloss

I have to agree with Evelyn. Technically, my code uses AMD. But it's all still in one big file, because I can't figure out how to separate it out. Every person who posts about AMD and modules. provides the same few links - to ESRI and to DOJO documentation. I have read all of these dozens of times, but I just don't get how it applies to my work. I get the core concepts, but applying it to my existing code is a completely different story.

RavindraSingh

yes, Agree with Tracy.

There has to be a baby crawl steps guide .

TyroneBiggums

I would pull out one thing and try to add it to a stand alone file.

1. Start by creating the dojoConfig file in the example above if you don't have one, and adding a script tag in your huge file to reference it.

2. Change the packages line to just one package, and create a location for it in your base root. Packages could look like this: packages: [ { name: 'whatYouReferenceYourModuleWith', location: locationPath + 'folderNameAtYourRoot', main: 'fileNameInAformentionedFolderName} ]

3. Create said folder and .js file referenced above.

4. In file in step 3, add this code: define(function() { return { lookAtMeNow: function() { return 'oh hi'; } } });

5. In your one huge file, add this somewhere (somewhere that you know the DOM is read ... through jquery, dojo, whatever): require(['whatYouReferenceYourModuleWith'], function (whatYouReferenceYourModuleWith) { alert(whatYouReferenceYourModuleWith.lookAtMeNow) } });

In short,

1. Config file makes the modules available

2. Create a package that points to one of your files

3. Create a js file that your config points to

4. define some code for that module

5. require the module defined in step 4 by the name provided in step 2. Note: leaving off the main: 'moduleName' in the package will cause the config to look for main.js (which is what was in the original post).

disclaimer: That's as baby stepped as it can be, pretty much, and I didn't test that actual syntax.

Nehmen Sie an der Diskussion teil

Angemeldete Mitglieder können Beiträge verfassen, Updates folgen und mehr. Neu hier? Registrieren Sie ein kostenloses Konto.

Schnellzugriffe

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.