¿Qué marco de trabajo es el mejor para implementar una aplicación de manera robusta, usando el ArcGIS Server JS API?

Question

Sobre el Foro Esri El usuario Matt Moyles sugirió que el enfoque utilizado en las muestras de Esri JS no es adecuado para el desarrollo robusto de una aplicación de mapeo web utilizando HTML, JavaScript y CSS:

El enfoque sugerido por ESRI para el desarrollo de aplicaciones en javascript es antiguo y anticuado. No recomendaría seguir las muestras. Dojo 1.7 soporta AMD con carga de dependencia asíncrona. Yo empezaría con la plantilla de calderilla del dojo y "trabajaría" el api del arcgis en eso. Las muestras no son adecuadas para desarrolladores de aplicaciones serias. Son en su mayoría sólo pruebas de fragmentos de conceptos.

Se debe desarrollar una aplicación seria con la ayuda de algún tipo de marco para ayudar a estructurar las cosas. ¡He estado usando dojox.mvc con gran éxito! Pero otras opciones incluyen cosas como backbone.js, spine.js, o incluso javascript MVC.

Dojo Boilerplate - https://github.com/csnover/dojo-boilerplate

• ¿Alguien está de acuerdo o en desacuerdo con esta declaración?
• ¿existen ejemplos en línea de mejores enfoques para el desarrollo de aplicaciones web utilizando el ArcGIS Server JS API?

Answer 1

Estoy de acuerdo con Moyles en que las muestras son sólo muestras y el boilerplate del dojo es un gran recurso, sin embargo en los snovers actuales el boilerplate no es una solución viable. Tienes dos versiones diferentes de dojo en marcha allí. La actual js api todavía usa la sintaxis clásica de require dojo 1.6.1 y no soporta AMD. Estoy seguro de que la nueva js api se construirá en 1.7.x y como convertir los módulos clásicos de dojo.defined a AMD es mayormente trivial, yo elegiría esa ruta.

Si estás comenzando tu proyecto ahora entonces elegiría cualquier marco de lado del servidor que quisiera usar (si es necesario para su aplicación. Si es sólo un visor de una sola página sin requisitos del lado del servidor, entonces no complique demasiado las cosas). Podría ser rails, php, asp, lo que sea. Siga las mejores prácticas para su framework/idioma.

Entonces, como esri está construido en el dojo, ya está cargando un gran marco js para crear aplicaciones web a gran escala. Estructura tu código para que el cargador del dojo pueda cargar tus widgets y módulos con la sintaxis requerida por el dojo. Escribe los widgets y módulos del dojo, usa los dijits y las herramientas del dojo cuando sea necesario ( http://dojotoolkit.org/documentation/tutorials/1.6/declare , http://dojotoolkit.org/documentation/tutorials/1.6/recipes/custom_widget/ , http://dojotoolkit.org/documentation/tutorials/1.6/understanding_widget , http://dojotoolkit.org/documentation/tutorials/1.6/templated , http://dojotoolkit.org/documentation/tutorials/1.6/cdn ). No escribas en la línea j como lo hacen las muestras. Crear un construir para optimizar todo su código cuando llegue el momento de la producción.

Tienes que mantener tu esri y el código personalizado separado hasta cierto punto porque no ofrecen la fuente para la compilación - ya está construido y minado. A la herramienta de compilación no le gusta mucho eso.

EDITAR

Construí un herramienta de gruñido, esri_slurp para descargar el esri js api para que puedas usarlo como un paquete en tus aplicaciones. Esto te permite ejecutar la construcción y obtener un solo archivo.

Answer 2

Debería ser bastante obvio que las muestras no están destinadas a ser aplicaciones serias: son muestras.

Dicho esto, es mucho menos común, en el típico mundo de Internet, usar algo como Espina dorsal que usar el dojo, que es conocido por ser expansivo y complejo, pero a menudo innecesario.

Si pudiera describir más su objetivo, sería más fácil hacer una recomendación sólida. Cosas como Backbone están escritas para aplicaciones completas del lado del cliente - así que si realmente estás haciendo la mayor parte de tu trabajo en PHP o ASP o nodejs, es menos necesario. O si no necesitas varias páginas y vistas conectadas, puedes hacerlo fácilmente con sólo jQuery, o sin ninguna estructura.

Answer 3

Totalmente de acuerdo. ESRI es javascript api, siento que están compitiendo con ArcGIS Viewer por Flex. Las muestras no son más que una prueba de concepto de cómo puedes usar sus dijits... Deseo que sólo proporcionen una simple y pura API de javascript, y que dejen al usuario decidir qué marco de trabajo va a usar la gente como Bing, Google, Openlayers y varios otros...

Answer 4

jsRevolution, el nuevo marco de trabajo y herramienta de construcción de JavaScript de OmniStation, es el marco de trabajo más robusto disponible comercialmente en el mercado. Está diseñado para despliegues a gran escala de aplicaciones no triviales. Represento a OmniStation. Nuestros clientes pueden tener cientos o miles de clases, 10 o incluso cientos de desarrolladores. Mientras que estos clientes encontrarán el marco indispensable, jsRevolution es práctico para ciertas aplicaciones con tan sólo 25 clases.

Las muchas características de jsRevolution incluyen: Carga asíncrona, espaciado de nombres sin código, vista de código cambiable por URL (de Dev a Deploy), herencia sin código con validación de tiempo de construcción, interfaz sin código con validación de tiempo de carga, abstracción sin código (a veces denominada Mixin), la capacidad de identificar un recurso como una clase de instancia, multi-versión (múltiples versiones de clases dentro de la misma aplicación -simple de ejecutar), y muchas otras características.