Рамки ESRI: java vs javascript

Question

Я собираюсь разработать приложение для веб-сопоставления с продуктами ESRI, такими как ArcGIS Server и Image Server.

Я не могу найти хорошее сравнение между Java Web ADF и Javascript Framework. Они, конечно, отличаются друг от друга, потому что одна из них является полной средой, а другая - только клиентской, но она намного более кратким и шаг для начала минимален.

Другая проблема заключается в том, что Java Web ADF несовместим с нашим текущим сервером приложений (JBoss 4.2.2) и требует старую версию 4.0.2.

У кого-то есть опыт, который может мне помочь?

Большое спасибо.

Answer 1

Что вам нужно, зависит от того, что вы хотите. Если вы хотите создать только средство просмотра (в отличие от приложения, в котором пользователи могут добавлять (например, рисовать) географические данные), во что бы то ни стало, используйте javascript api!

Я работаю с веб-adf (v9.3) в течение некоторого времени и до сих пор разочарован на каждом шагу. В первую очередь за отсутствие надлежащей документации, но и по различным другим причинам, например, такие:

• Это требует использовать JSF эталонную реализацию, но это не позволяет использовать некоторые из его основных функциональных возможностей, таких как (f:). Это делает невозможным использование каких-либо систем шаблонов, таких как facelets.
• Много файлов, которые вы хотите настроить, жестко закодированы в jar-файлах esri. Например, карта ДОЛЖНА находиться под < формой>, которая должна быть первым элементом дерева DOM. Если нет, слушатели движения карты, такие как ContinueousPanListener, не могут найти карту и, следовательно, не смогут обновить положение карты.
• Невозможно закодировать свои страницы jsp в стиле xml, так как веб-adf вставляет фрагменты во многих местах вашего кода с помощью xslt.
• Его кривая обучения очень крутая и без надлежащих документов, вы будете искать дни или даже недели о том, как делать самые тривиальные вещи. Некоторые из них в конечном итоге могут быть совершенно невозможными или непрактичными, потому что вы не принимаете мышление Эсри.
• Интерфейс по умолчанию не очень интуитивно понятен. Вы, возможно, все же закончите работу над javascript, чтобы получить приложение, которое понравится вам.
• Для отмены функции требуется версия базы данных, которая непрактична/невозможна для приложения, которое одновременно обслуживает более 10 или около того пользователей, плюс, кругосветное путешествие на сервер для каждого действия отмены - это отходы.

Вкратце: вы можете создавать интересные приложения, и если вы знаете свои вещи, в этом секторе есть много работы, но если это просто «какой-то проект», я бы переключился на некоторые. . Любые! другие рамки, такие как openGeo ..

Answer 2

У меня нет прямого опыта работы с Java Web ADF, но я работал с .Net-версией, и теперь я работаю с Flex API.

Основная проблема с веб-ADF, которые я видел и слышал от других разработчиков, заключается в том, что они очень громоздки в использовании. Новые структуры (Javascript, Silverlight и Flex) намного легче, проще в использовании, и вы можете ускорить их быстрее. Например, тестовое приложение, которое я написал с помощью .Net ADF, заняло у меня почти три недели, прежде чем я сдался. В то время я отказался от использования ADF и просто сделал WebService вызовы с ArcGIS Server, поскольку это было легче сделать, чем пытаться выяснить ADF. Сравните это с использованием API Flex для аналогичного проекта, который я только начал на прошлой неделе, и у меня есть почти полное приложение с сегодняшнего утра.

Я бы избегал АПД и работал с API Javascript.

Answer 3

Веб-ADF была первой попыткой ESRI создать упрощенный API-интерфейс ArcGIS Server. Однако с течением времени Web ADF закончил свои собственные абстракции, которые были такими же сложными, как «стандартный» ArcGIS Server ArcObjects API, а не настолько мощный. Поэтому я бы рекомендовал более поздние воплощения ... javascript, flex и т. Д.

Answer 4

Его значение зависит от требований. I java web adf у вас может быть больше гибкости, чтобы использовать arcobjects по сравнению с java-скриптом api. Я использую .net adf & Мне нужно было перейти к jsapi. но из-за ограничения использования arcobject в jsapi я все еще использую web adf. Я думаю, что jsapi не выращивается по сравнению с веб-adf. для просто viwer & маленькая задача js api в порядке. но если вы создаете сложные задачи, то его необходимо придерживаться веб-adf.

Answer 5

Если вам необходимо отредактировать геопространственные данные, вам необходимо использовать веб-ADF, доступ к ArcObjects.

Если вы просто работаете с данными просмотра, возможно, некоторые красные линии, которые не сохраняются в вашей базе геоданных, тогда JavaScript API работает хорошо.

Геообработка может быть выполнена в JSAPI. Вы также можете публиковать модели и использовать их в JSAPI.

Я слышал, что новые API-интерфейсы API JavaScript будут иметь возможность редактировать в ближайшем будущем.

Как уже упоминалось, сеть ADF является широкой и довольно сложной. У него хорошая кривая обучения. Я только начал обнимать его и выяснять логику. Я использую .NET ADF v9.3.1 У меня не было много проблем с ним, как только я начал выяснять API. Это не для случайного пользователя.

Answer 6

Вы можете редактировать через JSAPI, используя службу геообработки. Версия 2.0 (из-за ArcGIS Server 9.4) будет иметь встроенные возможности редактирования. Тем не менее, если план включает в себя публикацию геопространственных данных через публичную страницу, этот план необходимо переосмыслить. Если вы работаете внутри, ArcGIS Engine, вероятно, лучший вариант.

Answer 7

Остановитесь далеко, далеко от Java Web ADF. Я предпочел бы держать горячие утюги в моих глазах, чем развиваться с УАПД. Это не сработает с другими структурами JSF, любая пользовательская функциональность приводит к тому, что вы пытаетесь разработать javascript, но только путем первого встраивания javascript в фрагменты страницы XSL. Это громоздко, запутанно, но, по крайней мере, оно медленное.

ESRI не рекомендует использовать Java Web ADF для любых новых приложений.

Answer 8

Мы только что прошли то же самое, и казалось бы, что API ESRI REST - это способ пойти, если вы хотите использовать легкое сервисное приложение с «богатым» интерфейсом, а не раздуванием ADF.

Существует хорошее резюме всех рамок ESRI на их сайте в Великобритании here.

Answer 9

Редактирование с помощью API REST и API-интерфейса клиента (JS, Flex, Silverlight) будет доступно в версии 10 (verison 9.4 renamed), которая будет выпущена летом 2010 года.

Эта ветка немного устарела, но я согласен с теми, кто предлагает не использовать Java ADF. Используйте API JavaScript, Flex или Silver light, поскольку они масштабируются намного лучше. Если вам необходимо выполнить действия ГИС на сервере, используйте API SOAP в пользовательской веб-службе. Посмотрите только на ArcObjects, когда вам обязательно нужно, а затем убедитесь, что вы используете служебную программу или расширение сервера, чтобы дать вам максимальную возможность быстро сделать онлайн-приложение.

http://edndoc.esri.com/arcobjects/9.2/net_server_doc/developer/samples/web_applications/arcgis_simple_server_object_extension/8e8b2bf6-1877-4c48-80fe-266f5fa70f57.htm