views:

681

answers:

10

I'm about to develop a web mapping application with ESRI Products like ArcGIS Server and Image Server.

I can't find a good comparison between the Java Web ADF and the Javascript Framework. They're of course different because one is a full environment and the other is only client side but it's much more concise and the step to start is minimal.

Another problem is that the Java Web ADF is not compatible with our current application server (JBoss 4.2.2) and require an old 4.0.2 version.

Someone out there has experience that can help me?

Many thanks.

+5  A: 

I don't have direct experience with the Java Web ADF, but I have worked with the .Net version and am now working with the Flex API.

The main problem with the Web ADFs that I have seen and heard from other developers is that they're very cumbersome to use. The newer frameworks (Javascript, Silverlight, and Flex) are much lighter-weight, easier to use, and you can up to speed much quicker with them. For example, a test application I wrote withg the .Net ADF took me almost three weeks before I gave up on it. At that time I gave up using the ADF and just did WebService calls against ArcGIS Server since that was easier to do than to try to figure out the ADF. Contrast that to using the Flex API on a similar project, which I just started last week, and I have an almost complete app as of this morning.

I would avoid the ADFs and go with the Javascript API.

Michael Todd
+3  A: 

What you need depends on what you want. If you want to create just a viewer (as opposed to an application in which users can add (e.g. draw) geographical data), by all means, use the javascript api!

I've been working with the web adf (v9.3) for some time now and am still frustrated at every turn. Primarily for its lack of proper documentation, but also for various other reasons, such as these:

  • It requires you to use the jsf reference implementation, but it does not allow you to use some of its basic functionality, such as (f:)subviews. This makes it impossible to use any templating systems, such as facelets.
  • Lots of stuff you want to be able to configure is hardcoded in esri's jar files. For example, the map MUST be directly under < form> which must be the first element of the DOM tree. If not, map-movement listeners such as the ContinueousPanListener are unable to find the map and hence fail at updating the map position.
  • It's impossible to code your jsp pages in xml style, since the web adf inlines pieces of at a lot of places in your code, with xslt.
  • Its learning curve is very steep and without the proper docs, you'll be looking for days or even weeks on how to do the most trivial things. Some of these end up to be downright impossible or impractical, because you're not adopting esri's mindset.
  • The default interface is not very intuitive. You may still end up doing lots of work in javascript to get the way the application draws to your liking.
  • The undo functionality requires a versioned database, which is impractical/impossible for application that serves more than 10 or so users at the same time, plus, the round trip to the server for every undo action is a waste.

In short: You can make some interesting apps and if you know your stuff, there's work a plenty to be found in the sector, but if its just for 'some project', I'd switch to some.. any! other framework, such as openGeo..

Roel
I accepted your answer because is the most complete, but thanks to everybody for yours time.
Luke
+3  A: 

Web ADF was ESRI's first attempt to create an ArcGIS Server simplified API. However, as time progressed, the Web ADF ended up with its own abstractions that were as complicated as the "standard" ArcGIS Server ArcObjects API and not as powerful. Therefore, I would recommend the later incarnations... javascript, flex, etc

rburhum
A: 

Its depends on the requirements. I java web adf you could have more flexiblity to use arcobjects compared to java script api. i am using .net adf & i was wanted to move to jsapi. but due to limitation of arcobject usage in jsapi i am still with web adf. I think still jsapi is not grown as compared to web adf. for just viwer & small task js api is fine. but if you are creating complex tasks & geoprocessing then its worth to stick with web adf.

Pragnesh Patel
A: 

there is good blog post on ESRI Developer Blog today. have a look.

Pragnesh Patel
A: 

If you need to edit geospatial data then you have to use the Web ADF which is access to the ArcObjects.

If you are just working with viewing data maybe some redlines that are not saved to your geodatabase then JavaScript API works nice.

Geoprocessing can be done in the JSAPI. You can also publish models and use them in the JSAPI.

I hear that the newer APIs - JavaScript API will have the ability to edit in the near future.

As is mentioned the web ADF is broad and fairly complex. It has a good learning curve to it. I have just started getting my head around it and figuring out the logic. I am using the .NET ADF v9.3.1 I have not had many problems with it once I started figuring out the API. It is not for the casual user.

shawn deutch
A: 

You can do editing via the JSAPI using a geoprocessing service too. Version 2.0 (due out with ArcGIS Server 9.4) will have editing capabilities built in. That said, if a plan involves exposing editing of geospatial data via a public facing webpage, that plan needs to be rethought. If you are working internally, ArcGIS Engine is probably a better option.

Brett
A: 

Stay far, far away from the Java Web ADF. I would rather stick hot irons in my eyes than develop with the ADF. It doesn't work well with other JSF frameworks, any custom functionality results in you trying to develop javascript - but only by first embedding the javascript within XSL page fragments. It is cumbersome, confusing, but - at least it is slow.

ESRI is not recommending the Java Web ADF for any new applications.

Mike O
A: 

We've just gone through the same thing and it would appear the ESRI REST APIs are the way to go if you want a lightweight services based application with a 'rich' front end, rather than the ADF bloat.

There's a good summary of all the ESRI frameworks on their UK site here.

Rowan
A: 

Editing with the REST API and the client API's (JS, Flex, Silverlight) will be available at version 10 (verison 9.4 renamed) which will be released in Summer 2010.

This thread is a bit old now, but I concur with those who suggest not using the Java ADF. Use the JavaScript, Flex or Silver light API's as they scale much better. If you need to perform GIS actions on the server then use the SOAP API in a custom web service. Only look at ArcObjects when you definitely have to and then make sure you use a Server Object Utility or extension to give yourself the best chance of making a online application that runs quickly.

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

The Abbott of Monkseaton