<\/P>
Uma pergunta nos fóruns<\/A> surgiu recentemente que pensei que talvez eu pudesse explicar melhor em forma de post no blog ao invés de uma única resposta. Como faço para migrar do Dojo legado para o estilo moderno Dojo AMD?<\/EM> Essa é uma pergunta válida, e uma com a qual eu tive dificuldades<\/A> quando o Dojo 1.7 foi lançado. Você pode consultar a Migração para 3.0<\/A> na documentação para ter uma ideia das mudanças.<\/P><\/P>Acho que neste ponto, as pessoas já estão familiarizadas que dojo.declare agora é um módulo chamado dojo\/_base\/_declare, mas é o uso dos pedaços AMD que causa alguma confusão.<\/P><\/P>Acho que alguns dos obstáculos são apenas entender o AMD. Tive alguns momentos de confusão com ele no começo, pois não tinha certeza quando usar require<\/SPAN> ou quando usar define<\/SPAN> ou como trabalhar com módulos. Minhas dificuldades iniciais foram com requirejs e eu não tinha um mentor para realmente me ajudar, mas vasculhei a documentação e postagens em grupos do Google para descobrir, então quando o Dojo 1.7 foi lançado com o carregador AMD, eu estava melhor preparado.<\/P><\/P>Vamos simplificar ao máximo e mostrar o que você verá na maioria dos exemplos no site dos Desenvolvedores ArcGIS<\/A>.<\/P>require(["esri\/map", "dojo\/domReady!"], function(Map) { var map = new Map("map", { center: [-118, 34.5], zoom: 8, basemap: "topo" });});<\/PRE><\/P>Aqui está o temido método require<\/SPAN>. Se você já trabalhou com C++\Java ou linguagens similares pode estar familiarizado com a função main()<\/SPAN>. Esta é a função que ocorre quando um aplicativo inicia, é onde a festa começa<\/EM>. O método require<\/SPAN> é a função principal do AMD<\/STRONG>. Então em algum lugar nos módulos da API ArcGIS for JavaScript baixados via CDN quando você adiciona a tag script à sua página há um arquivo JavaScript chamado map.js<\/SPAN> em uma pasta chamada esri<\/SPAN> que se parece com isto.<\/P><\/P>define(['dependency1', 'dependency2'], function(dependency1, dependency2) { var Map; \/*coisas mágicas de unicórnio*\/ return Map;});<\/PRE><\/P>O método require<\/SPAN> vai procurar esse arquivo e carregá-lo assincronamente para sua aplicação. Quando terminar de carregar, a função na sua aplicação é então chamada, as coisas que definem o que é um Map (muito existencial<\/EM>) são retornadas da função. Note que este módulo tem suas próprias dependências, e na função elas são carregadas na ordem em que são solicitadas. ISSO É IMPORTANTE. A ordem importa<\/EM>. Essas dependências podem ser funções ou objetos, ou talvez strings. Abaixo está um diagrama do meu livro<\/A> que pode ajudar você.<\/P><\/P><\/P><\/P>No meu livro, uso um arquivo chamado run.js<\/SPAN> que faz o método require<\/SPAN> definindo minha dojoConfig<\/A> e um main.js<\/SPAN> que realmente começa a fazer o trabalho. Esse é apenas meu estilo, mas não é o estilo definitivo.<\/P><\/P>Algumas pessoas se confundem com o uso de main.js<\/SPAN> e honestamente, eu também no começo. Um bom ponto de referência é o tutorial de Módulos Avançados<\/A> do Dojo. Vou citar a parte importante sob Configurando o Loader.<\/P><\/P>main (opcional, padrão = main.js😞) usado para descobrir o módulo correto para carregar se alguém tentar requerer o próprio pacote. Por exemplo, se você tentar requerer "dojo", o arquivo real que seria carregado é "\js\dojo\main.js". Como sobrescrevemos essa propriedade para o pacote "my", se alguém requerer "my", eles realmente carregariam "\js\my\app.js".Se tentássemos requerer "util", que não é um pacote definido, o loader tentaria carregar "\js\util.js". Você deve sempre definir todos os seus pacotes na configuração do loader.Aqui está um exemplo de como pode ser um dos meus dojoConfigs, meu ponto de entrada require.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']);
Acho que neste ponto, as pessoas já estão familiarizadas que dojo.declare agora é um módulo chamado dojo\/_base\/_declare, mas é o uso dos pedaços AMD que causa alguma confusão.<\/P>
Acho que alguns dos obstáculos são apenas entender o AMD. Tive alguns momentos de confusão com ele no começo, pois não tinha certeza quando usar require<\/SPAN> ou quando usar define<\/SPAN> ou como trabalhar com módulos. Minhas dificuldades iniciais foram com requirejs e eu não tinha um mentor para realmente me ajudar, mas vasculhei a documentação e postagens em grupos do Google para descobrir, então quando o Dojo 1.7 foi lançado com o carregador AMD, eu estava melhor preparado.<\/P><\/P>Vamos simplificar ao máximo e mostrar o que você verá na maioria dos exemplos no
require(["esri\/map", "dojo\/domReady!"], function(Map) { var map = new Map("map", { center: [-118, 34.5], zoom: 8, basemap: "topo" });});<\/PRE><\/P>Aqui está o temido método require<\/SPAN>. Se você já trabalhou com C++\Java ou linguagens similares pode estar familiarizado com a função main()<\/SPAN>. Esta é a função que ocorre quando um aplicativo inicia, é onde a festa começa<\/EM>. O método require<\/SPAN> é a função principal do AMD<\/STRONG>. Então em algum lugar nos módulos da API ArcGIS for JavaScript baixados via CDN quando você adiciona a tag script à sua página há um arquivo JavaScript chamado map.js<\/SPAN> em uma pasta chamada esri<\/SPAN> que se parece com isto.<\/P><\/P>define(['dependency1', 'dependency2'], function(dependency1, dependency2) { var Map; \/*coisas mágicas de unicórnio*\/ return Map;});<\/PRE><\/P>O método require<\/SPAN> vai procurar esse arquivo e carregá-lo assincronamente para sua aplicação. Quando terminar de carregar, a função na sua aplicação é então chamada, as coisas que definem o que é um Map (muito existencial<\/EM>) são retornadas da função. Note que este módulo tem suas próprias dependências, e na função elas são carregadas na ordem em que são solicitadas. ISSO É IMPORTANTE. A ordem importa<\/EM>. Essas dependências podem ser funções ou objetos, ou talvez strings. Abaixo está um diagrama do
No meu livro, uso um arquivo chamado run.js<\/SPAN> que faz o método require<\/SPAN> definindo minha
Aqui está um exemplo de como pode ser um dos meus dojoConfigs, meu ponto de entrada require.
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']);
No método require, o primeiro parâmetro é o objeto dojoConfig, o segundo é a dependência ['app'], este é meu ponto de entrada. Então de acordo com a documentação acima, simplesmente pedindo por ‘app’, por padrão ele procurará por ‘app/main.js’.
Se tudo isso ainda estiver muito confuso, você ainda pode simplesmente definir um objeto global dojoConfig para configurar seus pacotes e fazer um require mais antigo simples para iniciar sua aplicação. Algo assim.
<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 }; </script> <script>require(['app/start'], function() {})</script></body>
Espero que isso esclareça algumas coisas.
Você pode aprender muito disso através da documentação do Dojo e especialmente do tutorial de Módulos CDN. Esta página cobre algumas partes do Dojo Legado para Moderno em profundidade. Aqui está um guia de migração. Aqui está um conversor de Dojo legado para AMD que você também pode tentar. Nunca usei, mas pode ser um bom ponto de partida. Duvido que funcione 100% com todos os módulos Esri, mas vale a pena tentar.
Espero que isso ajude um pouco se você ainda estiver tendo dificuldades para migrar aplicações Dojo Legado para Dojo moderno. Pode levar algum tempo para assimilar tudo, mas vai acontecer. Para mais dicas e truques geodev, confira meu blog.
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.
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.
yes, Agree with Tracy.
There has to be a baby crawl steps guide .
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.
Membros conectados podem postar, seguir atualizações e mais. Novo aqui? Registre uma conta gratuita.
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.