JSF for Web Mapping
JavaServer Faces (JSF), and ASP.Net, are relatively new event driven web application frameworks. They as designed to enable developers, who are familiar with tools like Visual Basic and Delphi, to easily create web applications. The developers drag and drop components onto a canvas (representing a web page), and then write event handler code to glue it all together.
Leaving aside the relative merits of drag-n-drop development, I’d like to focus on the use of event driven web application frameworks for creating map-centric web applications. By “map-centric” I’m referring to web applications where the user spends a lot of time zooming, panning, switching layers on/off, and querying spatial features.
Both JSF and ASP.Net are component-based web frameworks. In short, this means that actions performed by the user in their web browser are sent back to the server where those actions trigger events. Examples include submitting a form, and clicking on a navigation link.
This approach works fine for data-centric business applications. These types of applications are built around the concept of submitting chunks of data to a server for processing. Put another way, data-centric application are “transactional”, both from the user’s point of view and the developer’s point of view.
So what’s the problem? Well, map-centric web applications are not data entry forms. They are a richer environment because, well, they contain maps. Maps on the Web are a continuous resource. They change when you pan (X, Y), and when you zoom (Z), but to the user it’s still the same map. Maps are not perceived as “transactional”.
The user is not expecting the map to disappear, or the entire web page to reload, every time they interact with the map. That’s a poor user experience. Yet, this is what happens when you build a web mapping application using the Java (JSF) and .Net Application Developer Frameworks that ship with ArcGIS Server 9.0. By default, every time the user pans, zooms, turns a layer on or off, or queries a spatial feature, the entire web page reloads.
Hey, it gets the job done, doesn’t it? Well yes, but it’s clumsy. Click-n-wait web mapping is not productive for the end user, and I prefer to do better for my clients. After all, they’ve all seen Google Maps by now.
So what are your choices?
1. Subvert the Framework
If you have no choice but to use a web application framework like JSF or ASP.Net then you will have to write some code to work around the limitations of the framework. This is not ideal. Frameworks are supposed to make developers more productive by letting them focus on the application rather than workarounds.
2. Do It Yourself
Building it yourself is likely to be time consuming, but you will get exactly what you need. Yet, it’s possibly better to…
3. Use Another Framework
Use a presentation framework that will let you develop the web applications that suit your needs. This can also save considerable time and money, especially when used for multiple projects. There are several commercial and open source options, including:
- Internet Mapping Framework (IMF) from Moxi Media (commercial)
- Community Map Builder (open source)
Of course, it helps if your map server support well known interfaces, like WMS or ArcXML. ArcGIS Server doesn’t provide such interfaces, but in its defence, it was not designed to be just a map publishing platform.
4. Use a Thicker Client
For highly interactive web mapping applications the use of a thicker client is well worth considering. i.e. A browser plug-in or Java applet. A lot of people scoff at this idea because it’s not a pure browser client, but it does have its merits.
Data can be transmitted across the network in highly compressed formats, and cached in the browser. Vectors can be live selectable objects in the browser, rather than just pixels in a dumb image. This lets you do things like select features by region or attribute, create buffers, etc, without having to send a request to the server.
Tools like iDelve, Image Web Server, and MapGuide have been providing these capabilities for years.
There are plenty of options. However, I’m not convinced that the relatively new component-based web application frameworks like JSF and ASP.Net are the right way to go for map-centric web applications. The game has already moved on.
Steve Citron-Pousty — 2 July 2005, 16:06
I'm in favour of components, definitely. The real question that I'm trying to answer for myself is whether MVC/Model-2 frameworks are the right thing for web applications. Yup, and I'm not the only who has reservations. I'm crystalising some thoughts. Will post on this soon.
Getting back to web mapping applications, a map-centric application built on the Java ADF is likely to contain only a small number of views (possibly just one). i.e. Almost every time the user interacts with the map it reloads the same view. Two of the advantages of Model-2 architectures are that it centralises control logic, and it decouples the views. However, if there is limited page flow, and a small number of views, then the benefit provided by a complex framework is marginal.
Andrew Hallam — 5 July 2005, 06:41
And even in your use case it pays to think at the level of abstraction provided by components and events rather than HTTP parameters and views. That way you are more or less alleviated of the notion of working with the "web" and instead can focus on your business needs.
I agree that the web still has caveats like refreshing the entire page rather than just the parts you are interested in... But with AJAX / XML requests this is changing too... And IMO, components of the future will support this scenario... So if you were already using these components and they upgraded themselves to support partial refreshes, you inherit that behavior readily.
Keyur Shah — 6 July 2005, 13:54
My issue is not with the use of web application frameworks, per se. Frameworks are productivity tools, and I agree that while they have a learning curve they can have longer term benefits.
What I do have issues with is how most web application frameworks fight against the nature of the Web. They make it difficult to create an application that leverages the built-in goodness of the HTTP protocol. Examples from the JSF 1.1 Reference Implementation are:
The first issue is going to be addressed in a future release, but I'm guessing that will come at a cost of more code and complexity. I can probably work around the second issue by writing more code, but that increases application fragility and decreases my productivity.
I also have a gripe about frameworks that provide developer productivity at the cost of end user experience. The full page refresh in the Java ADF is a good example. I'd much rather have a DHTML client that talks to stateless map services. (Sounds sort of like WMS, doesn't it.) :-)
Point taken on the evolution of components, assuming such upgrades don't require a rewrite of the application. I've also subscribed to your blog, and Steve Citron-Pousty's. Thanks to both of you. Please keep blogging.
Andrew Hallam — 7 July 2005, 06:52