Scripting your application

No doubt the biggest challenge in developing interactive Internet applications is the scripting/programming involved. One could write several books about this subject, the aim of this section is merely to demonstrate the diversity of this subject and provide a few examples which were implemented using completely different programming techniques.

We have found that many of our clients are somewhat confused as to where the OpenGIS WMS server ends and custom web programming begins. Some of them were hoping for an “out-of the box” solution including a customizable client interface running in the visitor’s web browser.

However, because the kind of functionality required for real-life applications can be very diverse and there is a range of possible programming tools, web browsers and browser Plug-ins that could be employed, there is no such thing as a “standard client” included with our product. We do however provide examples for you to work from.

To develop your own web mapping application, most likely some serious programming will be required, and developing interactive web applications using DHTML can be a real challenge. Also, besides DHTML, there are several other client technologies you could employ which provide a higher level of interactivity, like Java and Flash “applets”

Before downloading the sample scripts provided by us and setting them up on your system, we strongly recommend you read the brief introduction to the OpenGIS WMS protocol in the next chapter. This will give you a basic understanding of how the WMS protocol and server work before digging into the specifics of web programming.

We hope you understand that the free user support we can provide is limited to getting the basic WMS server and sample scripts to work. If you need more assistance to develop your specific application, you can use our custom programming services (ASP, ASP.NET or Flash) on a consultancy basis.

WMS connector script

With the installation of the software, a virtual folder will be added to the default web site in IIS, which will be accessible as http://localhost/wms/ and provide a common connector to the WMS server for your application. The connector consists of ASP and ASP.NET based script containing only a few statements to interface the WMS server to the HTTP context provided by IIS.

We used ASP/ASP.NET for these as these languages seem to be the most straightforward way to provide a connector to IIS which is capable of passing on text and binary images to the HTTP request.

However, this does not mean that you are stuck with ASP or ASP.NET as a development platform. With the WMS connector in place you can use virtually any scripting language for the rest of the application. Using the WMS protocol, you pass on a http request to the WMS connector and it will return an image over http, regardless of the scripting language you prefer to work with.

The connector script can be either wms.asp or wms.ashx for the ASP respectively ASP.NET implementation. Using the ASP.net version should provide some performance benefits if you have the .NET framework installed, otherwise the operation of the connector script is identical.

Programming DHTML clients, mixed languages and incompatible web browsers

The HTML standard which formed the classic “language” of internet as we know it today, was originally designed to render static content. As browsers like Netscape and MSIE evolved, the need for more interactive web applications demanded the development of new standards, like the JavaScript scripting language. Unfortunately, the browser “war” between Netscape and Microsoft hampered the development of open (W3C) standards and the result is what we sometimes call “DHTML Hell”.

DHTML is in fact a mix of HTML, client side Javascript and Cascading Style Sheets (CSS) which were independently developed by Microsoft and Netscape. Given the historical lack of standardization much effort will go into resolving compatibility issues rather then adding new features, especially scripting things like mouse events and dynamic behavior on the client side can be a daunting task. Besides the compatibility issues, web programming is completely unlike more traditional programming models, a web page simply was never intended to provide the kind of interactivity a locally installed Windows application can.

In addition to the DHTML code (HTML / CSS / Javascript) which is required to provide a user interface in the Browser, in most cases part of the application logic will be programmed on the server. A wide variety of server side scripting languages could be employed (ASP, PHP, ColdFusion, Perl, JSP etc.) but unfortunately we can only provide full support for ASP and ASP.NET

As you can see from our ASP sample scripts, these make up a remarkable ‘spaghetti’ mix of HTML, CSS, JavaScript and VBScript (ASP) and getting things like mouse events to work properly with most common browsers was a far from trivial task.

Using the ASP sample scripts

For demonstration and training purposes, we have developed an ASP based sample script we have been running for several years now. You can find it in working order in our Gallery.

You can use the IIS console to create either a subweb or a virtual directory and unzip the ASPSample.zip file there.

Then you may need to create an “Application Scope”, depending on the type of folder and IIS version this may happen automatically.

The screen shot on the right shows the recommended application settings. For IIS version 4 or 5 we recommend you set the Application Protection to High to avoid possible conflicts with other applications running on the web server.

By default, the ASP sample script will use the same “SAMPLE” map that was setup during the installation.

If you have downloaded the entire world map data set, or created your own map, you only need to change a few statements in global.asa (line 12/13) to change the WMS name to the name you assigned to your map in the WMS control panel. (see previous section)

In these sample scripts, we have incorporated the basic mouse events, buttons etc. a typical web mapping application would need, as well as a drop down list of countries to zoom in on.

In many cases, customizing this sample script to fit your needs may be the fastest way to develop your application, but in some cases it may be better to start from scratch using the programming environment you are most familiar with.

Using the Flash sample client

One way to escape ‘DHTML hell’ and provide more interactivity on the client is to work with a Browser “Plug-in” like Java applets or theincreasingly popular Macromedia Flash plugin. We have little experience with Java applets but we do provide a Flash based client example, which works very nice in either browser.

Macromedia Flash is most commonly used for the design and scripting of animations and other dynamic content for web sites. Over the years Flash evolved to a more powerful development tool and it includes a JavaScript like programming language called actionscript. The major benefits of working with flash:

  • use a single programming language/model for your application, instead of mixing HTML, CSS, JavaScript, ASP
  • more interactivity can be achieved on a web page, you can do many things which are impossible using DHTML
  • Flash is a compiled, protected language, so no-one can copy the source code you worked on so hard
  • Since flash runs using a Plug-in, your application is less effected by browser incompatibilities
  • 90% of internet browsers already have the Flash Plug-in, so you might as well use it…

Once the Flash client has been developed and compiled to a SWF file, you can simply insert this into any web page using a straightforward<OBJECT> or <EMBED> tag which loads the Plug-in and passes along some parameters, a sample HTML file is included with the Flash example you can find in the downloads section. To demonstrate the convenience of inserting the Flash client into existing web pages, we have inserted it right here for you to try:

The code to insert a flash client in to a HTML page look like this:

<OBJECT classid=”clsid:D27CDB6E-AE6D-11cf-96B8-444553540000″ codebase=”http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=6,0,0,0″
width=”720″ height=”445″ align=”middle”>
<PARAM name=movie value=”http://www2.demis.nl/wms/MapClip.swf?WMS=WorldMap&BBox=-180,-90,180,90″>
<PARAM name=loop value=false>
<PARAM name=menu value=false>
<PARAM name=quality value=low>
<PARAM name=scale value=noscale>
<PARAM name=salign value=LT>
<PARAM name=wmode value=opaque>
<PARAM name=devicefont value=true>
<PARAM name=bgcolor value=#CCFAFF>
<EMBED src=”http://www2.demis.nl/wms/MapClip.swf?WMS=WorldMap&BBox=-180,-90,180,90″
loop=false menu=false quality=low scale=noscale salign=LT wmode=transparent devicefont=true bgcolor=#CCFAFF
width=”720″ height=”445″ swliveconnect=true id=”MapClip” align=”middle” type=”application/x-shockwave-flash” pluginspage=”http://www.macromedia.com/go/getflashplayer”></EMBED>

You may have noted parameters can be passed, like WMS name and BBOX, but otherwise the behavior of the flash client can only be altered using the MacroMedia Flash compiler, if you have access to the source code (.FLA file)

A limitation of the flash client is that due to the security “sandbox” model, you cannot load content from another domain then where the flash client is hosted. The Demis WMS server and the web server where the flash applet is hosted must be within the same domain.