<\/HEAD>
<\/P>
De vez em quando, alguém me pergunta sobre como eles devem estruturar seu app ArcGIS JS API. No meu livro<\/A>, eu recomendo a seguinte estrutura de app:<\/P><\/P>
app\/<\/STRONG><\/SPAN><\/P> |-- css\/<\/STRONG><\/SPAN><\/P> |-- js\/<\/STRONG><\/SPAN><\/P> |-- controllers\/<\/STRONG><\/SPAN><\/P> |-- services\/<\/STRONG><\/SPAN><\/P> |-- utils\/<\/STRONG><\/SPAN><\/P> |-- widgets\/<\/STRONG><\/SPAN><\/P> |-- main.js<\/STRONG><\/SPAN><\/P> |-- run.js<\/STRONG><\/SPAN><\/P> |-- index.html<\/STRONG><\/SPAN><\/P><\/P>Eu usei essa estrutura de app para muitos projetos e funcionou bem. Normalmente meu run.js<\/STRONG> parecia assim:<\/P>(function() {
'use strict';
var pathRX = new RegExp(\/2F[^\/2F]+$\/2F)
, locationPath = location.pathname.replace(pathRX, '');
require({
packages: [{
name: 'controllers',
location: locationPath + 'js/controllers'
}, {
name: 'widgets',
location: locationPath + 'js/widgets'
}, {
name: 'utils',
location: locationPath + 'js/utils'
}, {
name: 'services',
location: locationPath + 'js/services'
}, {
name: 'app',
location: locationPath + 'js',
main: 'main'
}]
}, ['app']);
})();<\/PRE><\/P>Isso funciona muito bem. Mas uma coisa que não leva em consideração é tratar o app e todos os submódulos como um pacote app<\/STRONG>. Isso está mais relacionado a tratar meus módulos como pacotes ao usar o CDN. Qual é a diferença?<\/EM> Que bom que perguntou!<\/P><\/P>Digamos que você queira construir sua aplicação. Talvez você vá utilizar o
ArcGIS optimizer<\/A> ou esri-slurp<\/A>, que tem um ótimo exemplo aqui<\/A>, aliás. Você vai querer tratar sua aplicação como seu próprio pacote. O que quero dizer com isso? Bem, vamos dar uma olhada em como você usa a ArcGIS JS API.<\/P><\/P>
require(['esri/map', 'dojo/declare'], function(Map, declare) {\/*coisas legais*\});<\/PRE><\/P>Nesse caso, esri<\/STRONG> é um pacote e dojo<\/STRONG> é um pacote. Existem outros pacotes incluídos na API, como dgrid<\/STRONG>, dstore<\/STRONG>, e diijt<\/STRONG>. Isso porque quando você usa o sistema de build Dojo<\/A>, ele sabe como referenciar os arquivos. Então você pode naturalmente empacotar sua aplicação como seu próprio pacote, chamado app<\/STRONG>. Você pode chamá-lo de Sally se quiser, mas vamos assumir que app funciona muito bem.<\/P><\/P>Então hoje em dia, a forma que eu gosto de estruturar meu app é parecida com isso.<\/P>index.html<\/STRONG><\/SPAN>
dojoConfig.js<\/STRONG>
app\/
|-- styles\/
|-- models\/
|-- services\/
|-- utils\/
|-- widgets\/
|-- main.js
|-- app.profile.js
|-- package.json
|-- config.json
Aqui, eu tenho um arquivo dojoConfig que faz uma configuração básica. Pode ser assim:
var dojoConfig = {
async: true,
parseOnLoad: true,
isDebug: true,
deps: ['app/main']
}
};
Ok, isso assume que vou usar esri-slurp para baixar a API e usar o bower para instalar outras dependências. Se eu estivesse usando isso como um CDN, eu adicionaria a propriedade packages assim:
packages: [{
name: 'app',
location: location.pathname.replace(/\/[^2F]+$/, '') + 'app'
}]
É isso.
Ok, aguente firme um segundo. O que é essa bobagem de app.profile.js? Esse arquivo define algumas resourceTags para nosso pacote app. Isso basicamente diz ao sistema de build Dojo que meu pacote está usando AMD. Um colega me falou sobre isso, eu não achava que precisava, mas o sistema de build Dojo fica insistindo se você não tem isso. Parece assim:
var profile = (function(){
return {
resourceTags: {
amd: function(filename, mid) {
return /\.js$/.test(filename);
}
}
};
})();
O arquivo package.json informa ao sistema de build Dojo onde encontrar o app.profile para usar.
{
"name": "myapp",
"version": "1.0.0",
"main": "main",
"description": "Demo app.",
"homepage": "",
"dojoBuild": "app.profile.js"
}
O arquivo config.json é algo que venho usando há anos nos meus apps ArcGIS JS API. Basicamente são configurações ou como o mapa aparece ou configurações para widgets. Posso usar esse arquivo ou chamar um serviço web para obter esses dados de configuração. Você pode ver um exemplo do que isso pode parecer aqui. O resto da aplicação é bem básico. Atualmente minha estrutura de aplicação é fortemente inspirada pelo ember-cli, pois é algo que tenho usado bastante ultimamente.
No entanto, se eu estiver usando React para construir minha UI, gosto de usar uma estrutura mais orientada ao Flux.
20index.html
20dojoConfig.js
20app\/
20& nbsp ;& ; nbsp ;|-- styles\/
20& ; nbsp ;|-- stores\/
20& ; nbsp ;|-- actions\/
20& ; nbsp ;|-- helpers\/
20& ; nbsp ;|-- views\/
20& ; nbsp ;|-- main.js
20& ; nbsp ;|-- app.profile.js
20& ; nbsp ;|-- package.json
20& ; nbsp ;|-- config.json
20
E também faria o mesmo se estivesse usando Angular, onde adotaria uma estrutura que usa diretivas em vez de views ou componentes. Atualmente estou trabalhando em um projeto com o Yeoman gerador para ArcGIS JS Apps, que você pode ver um app de demonstração aqui. Ainda é bastante experimental, mas pode ser útil para alguns.
O cmv-app tem uma estrutura de app interessante usando base de configuração similar a este starterkit em que eu estava trabalhando.
A chave aqui, goste ou não do meu conselho, é escolher uma estrutura que funcione para você. Você pode ter seu main.js funcionando como o controlador da aplicação e apenas ter uma pasta de widget com todos os seus elementos de UI. Novamente, desde que funcione para você, está tudo certo.
Eu vou fazer um post de blog de acompanhamento que fala sobre o próximo passo aqui, que é criar uma build personalizada da sua aplicação. Isso deve ser divertido!
Para mais dicas e truques geodev, confira meu blog.
