<\/HEAD>
<\/P>
De vez en cuando, alguien me pregunta cómo debería estructurar su aplicación ArcGIS JS API. En mi libro<\/A>, recomiendo la siguiente estructura de aplicación:<\/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>He usado esta estructura de aplicación para muchos proyectos y ha funcionado bien. Normalmente mi run.js<\/STRONG> se veía así:<\/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>Esto funciona bastante bien. Pero una cosa que no toma en cuenta es tratar la app y todos los submódulos como un paquete app<\/STRONG>. Esto se relaciona más con tratar mis módulos como paquetes cuando uso el CDN. ? ¿cuál es la diferencia?<\/EM> ¡Me alegra que preguntes!<\/P><\/P>Supongamos que quieres construir tu aplicación. Tal vez vas a utilizar el
ArcGIS optimizer<\/A> o esri-slurp<\/A>, que tiene un gran ejemplo aquí<\/A> por cierto. Querrás tratar tu aplicación como su propio paquete. ¿Qué quiero decir con eso? Bueno, echemos un vistazo a cómo usas la ArcGIS JS API.<\/P><\/P>
require(['esri/map', 'dojo/declare'], function(Map, declare) { /* cosas geniales */ });<\/PRE><\/P>En este caso, esri<\/STRONG> es un paquete y dojo<\/STRONG> es un paquete. Hay otros paquetes incluidos en la API, como dgrid<\/STRONG>, dstore<\/STRONG>, y diijt<\/STRONG>. Esto se debe a que cuando usas el Dojo build system<\/A>, sabe cómo referenciar los archivos. Así que puedes empaquetar naturalmente tu aplicación como su propio paquete, llamado app<\/STRONG>. Puedes llamarlo Sally si quieres, pero asumamos que app funciona perfectamente.<\/P><\/P>Así que hoy en día, la forma en que me gusta estructurar mi app es similar a esta.<\/P>index.html<\/STRONG>
dojoConfig.js<\\/strong>
app\\/<\\/strong>
 &amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;;#160&;#160&;#160&;#160&;#160&;#160&;#160&;#160&;#160&;#160&;#160&;#160&;#160&;#160&;#160&;#160&;#160&;#160&;#160&;#160&;#160&;#160&;#160&;#160&;#160&;#160&;#160|-- styles\\/<\\/strong>
 &;;|-- models\\/<\\/strong>
&;;|-- services\\/<\\/strong>
&;;|-- utils\\/<\\/strong>
&;;|-- widgets\\/<\\/strong>
&;;|-- main.js<\\/strong>
&;;|-- app.profile.js<\\/strong>
&;;|-- package.json<\\/strong>
&;;|-- config.json<\\/strong>
Aquí, tengo un archivo dojoConfig que hace una configuración básica. Podría verse así:
var dojoConfig = {
async: true,
parseOnLoad: true,
isDebug: true,
deps: ['app/main']
};
Ok, esto asume que voy a usar esri-slurp para descargar la API y usar bower para instalar otras dependencias. Si estuviera usando esto como un CDN, agregaría la propiedad packages así:
packages: [{
name: 'app',
location: location.pathname.replace(/\\[^\\]+$/, '') + 'app'
}]
Eso es todo.
Ok, ten paciencia un segundo. ¿Qué es esta tontería de app.profile.js? Este archivo define algunas resourceTags para nuestro paquete app. Básicamente le dice al sistema de compilación Dojo que mi paquete usa AMD. Un compañero me habló de esto, no pensé que lo necesitara, pero el sistema de compilación Dojo te molesta si no lo tienes. Se ve así:
var profile = (function(){
return {
resourceTags: {
amd: function(filename, mid) {
return /\.js$/.test(filename);
}
}
};
})();
El archivo package.json le indica al sistema de compilación Dojo dónde encontrar el app.profile para usar.
{
"name": "myapp",
"version": "1.0.0",
"main": "main",
"description": "Demo app.",
"homepage": "",
"dojoBuild": "app.profile.js"
}
El archivo config.json es algo que he estado usando durante años en mis aplicaciones ArcGIS JS API. Básicamente son configuraciones o cómo se ve el mapa o configuraciones para widgets. Puedo usar este archivo o llamar a un servicio web para obtener estos datos de configuración. Puedes ver un ejemplo de cómo podría verse aquí. El resto de la aplicación es bastante básico. Actualmente mi estructura de aplicación está fuertemente inspirada en ember-cli, ya que es algo que he estado usando mucho últimamente.
Sin embargo, si estoy usando React para construir mi UI, me gusta usar una estructura más orientada a generador para ArcGIS JS Apps, que puedes ver una app de demostración aquí. Todavía es bastante experimental, pero podría ser útil para algunos.
El cmv-app tiene una estructura de app interesante usando una base de configuración similar a este starterkit en el que estaba trabajando.
La clave aquí, te guste o no mi consejo, es elegir una estructura que funcione para ti. Podrías tener tu main.js funcionando como el controlador de la aplicación y simplemente tener una carpeta de widgets con todo tu contenido de UI. Nuevamente, mientras funcione para ti, estás listo.
Pronto escribiré un post de blog de seguimiento que habla sobre el siguiente paso aquí, que es crear una compilación personalizada de tu aplicación. ¡Eso debería ser divertido!
Para más consejos y trucos geodev, visita mi blog.
