Фреймворки ESRI: Java против JavaScript

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

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

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

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

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

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

Я бы избегал ADF и использовал Javascript API.

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

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

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

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

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

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

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

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

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

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

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

На их британском сайте есть хорошее резюме всех фреймворков ESRI здесь.

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

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

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