Marcos ESRI:java frente a javascript
https://stackoverflow.com/questions/1293460
-
18-09-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianPregunta
Estoy a punto de desarrollar una aplicación de mapas web con productos ESRI como ArcGIS Server e Image Server.
No puedo encontrar una buena comparación entre Java Web ADF y Javascript Framework.Por supuesto, son diferentes porque uno es un entorno completo y el otro es solo del lado del cliente, pero es mucho más conciso y el paso para comenzar es mínimo.
Otro problema es que Java Web ADF no es compatible con nuestro servidor de aplicaciones actual (JBoss 4.2.2) y requiere una versión antigua 4.0.2.
¿Alguien por ahí tiene experiencia que pueda ayudarme?
Muchas gracias.
Solución
Lo que se necesita depende de lo que desea. Si desea crear sólo un espectador (a diferencia de una aplicación en la que los usuarios pueden agregar (por ejemplo, dibujar) de datos geográficos), por todos los medios, utilice la API de JavaScript!
He estado trabajando con el ADF Web (v9.3) desde hace algún tiempo y todavía siento frustrado a cada paso. Principalmente por su falta de documentación apropiada, sino también por otras razones, tales como las siguientes:
- Se requiere el uso de la implementación de referencia de JSF, pero no se le permite utilizar algunas de sus funciones básicas, tales como (F:) subvistas. Esto hace que sea imposible el uso de cualquier sistemas de plantillas, como facelets.
- Un montón de cosas que desea ser capaz de configurar está codificada en los archivos jar de ESRI. Por ejemplo, el mapa debe ser directamente bajo
- Es imposible codificar sus páginas JSP en el estilo de XML, ya que la web Inlines piezas de ADF en un montón de lugares en su código, con XSLT.
- Su curva de aprendizaje es muy empinada y sin los documentos apropiados, se le busca por días o incluso semanas sobre cómo hacer las cosas más triviales. Algunos de ellos acaban de ser francamente imposible o poco práctico, porque no está adoptando la mentalidad de ESRI.
- La interfaz por defecto no es muy intuitivo. Usted todavía puede terminar haciendo un montón de trabajo en javascript para obtener la forma en que la aplicación dibuja a su gusto.
- La funcionalidad de deshacer requiere una base de datos versionado, lo cual es poco práctico / imposible aplicación que sirve a más de 10 o más usuarios al mismo tiempo, además, el de ida y vuelta al servidor para cada deshacer la acción es un desperdicio.
En pocas palabras: Usted puede hacer algunas aplicaciones interesantes y si usted sabe sus cosas, hay un montón trabajar que se encuentran en el sector, pero si es sólo por 'algún proyecto', me cambie a algunos .. cualquiera! otro marco, como OpenGeo ..
Otros consejos
No tengo experiencia directa con el ADF Web de Java, pero he trabajado con la versión .Net y ahora estoy trabajando con la API de Flex.
El problema principal con las ADF Web que he visto y oído de otros desarrolladores es que son muy difíciles de utilizar. Los marcos más recientes (Javascript, Silverlight, y Flex) son mucho más ligero, más fácil de usar, y que hasta pueden acelerar mucho más rápido con ellos. Por ejemplo, una aplicación de prueba que escribí withg el ADF .Net me llevó casi tres semanas antes de que me di por vencido en ella. En ese momento me di por vencido con el ADF y acabo de hacer llamadas WebService en contra de ArcGIS Server, ya que era más fácil de hacer que tratar de averiguar el ADF. Compárese eso con el uso de la API de Flex en un proyecto similar, que acabo de empezar la semana pasada, y tengo una aplicación casi completa partir de esta mañana.
Yo evitaría las ADF e ir con el API de JavaScript.
Web ADF fue el primer intento de ESRI para crear una API simplificada de ArcGIS Server. Sin embargo, a medida que pasaba el tiempo, el ADF Web terminó con sus propias abstracciones que eran tan complicado como la API de ArcObjects de ArcGIS Server "estándar" y no tan potente. Por lo tanto, recomiendo las encarnaciones posteriores ... JavaScript, Flex, etc.
Su depende de los requisitos. Me Java ADF web que podría tener más FLEXIBILIDAD utilizar ArcObjects en comparación con el API de Java script. estoy usando ADF .NET + i se quería mover a jsapi. pero debido a la limitación del uso de arcobject en jsapi estoy aún y Web ADF. Creo que todavía no se jsapi crecido en comparación con el alimentador automático de documentos web. por sólo viwer y api tarea pequeña js está muy bien. pero si va a crear tareas complejas y geoprocesamiento entonces vale la pena seguir con alimentador automático de documentos web.
Si usted necesita para editar datos geoespaciales entonces usted tiene que utilizar el ADF Web que es el acceso a los ArcObjects.
Si usted apenas está trabajando con datos de visualización tal vez algunas introducir correcciones que no se guardan en la geodatabase a continuación JavaScript API funciona bien.
El geoprocesamiento se puede hacer en el JSAPI. También puede publicar modelos y utilizarlos en el JSAPI.
he oído que las nuevas API - API JavaScript tendrán la posibilidad de editar en un futuro próximo
.Como se menciona el ADF web es amplio y bastante complejo. Tiene una buena curva de aprendizaje para él. Acabo de empezar a conseguir mi cabeza alrededor de ella y averiguar la lógica. Estoy utilizando el .NET ADF v9.3.1 No he tenido muchos problemas con él una vez que empecé a averiguar la API. No es para el usuario ocasional.
Puede hacerlo a través de la edición de JSAPI usando un servicio de geoprocesamiento también. Versión 2.0 (debido a cabo con ArcGIS Server 9.4) tendrá capacidades de edición incorporadas. Dicho esto, si un plan consiste en exponer la edición de datos geoespaciales a través de una página web orientada al público, que el plan tendrá que ser reconsiderada. Si está trabajando internamente, ArcGIS Engine es probablemente una mejor opción.
Manténgase muy, muy lejos del Java Web ADF.Prefiero clavarme hierros calientes en los ojos que desarrollar con el ADF.No funciona bien con otros marcos JSF, cualquier funcionalidad personalizada hace que usted intente desarrollar javascript, pero solo incrustando primero el javascript dentro de los fragmentos de la página XSL.Es engorroso, confuso, pero al menos es lento.
ESRI no recomienda Java Web ADF para ninguna aplicación nueva.
Hemos acaba de pasar por lo mismo y parece las API REST ESRI son el camino a seguir si quieres una aplicación basada con un frontal 'rico', en lugar de los excesos ADF servicios ligeros.
Hay un buen resumen de todos los marcos de ESRI en su sitio Reino Unido aquí .
Edición con la API REST y de la API de cliente (JS, Flex, Silverlight) estarán disponibles en la versión 10 (verison 9.4 a llamarse) que será lanzado en el verano de 2010.
Este hilo es un poco viejo ahora, pero estoy de acuerdo con aquellos que no sugiere el uso de Java ADF. Utilice el código JavaScript, Flex o plata luz de la API, ya que escala mucho mejor. Si necesita realizar acciones de SIG en el servidor a continuación, utilizar la API SOAP en un servicio web personalizado. Sólo mirar a ArcObjects cuando definitivamente tiene que y luego asegurarse de que utiliza una utilidad de objetos de servidor o la extensión para que tenga la mejor oportunidad de hacer una aplicación en línea que corre rápidamente.
