John R. Sawicki
ArcView is relatively new to most GIS users and application developers. As users and developers work with ArcView, specifically Avenue, to build single script tools or complex multiple script applications, the need and desire to integrate and leverage existing ArcView tools and applications increases. To maximize the reuse of Avenue scripts, an application framework should be used during script development. With this framework in place, user and developer will avoid, to a certain extent, problems when integrating tools and applications. The purpose of this paper is to outline an application framework designed to support the integration of applications specifically within the ArcView development environment. The goal of this framework is to enable developers to create a single project file that is organized in a way that promotes integration and also provides the "hooks" to incorporate additional tools and applications as they are developed. This paper discusses methods for building an ArcView application and focuses on issues such as the development environment, application infrastructure, and Graphical User Interface (GUI) management.
Today ArcInfo developers are moving from their UNIX workstations running ArcInfo to Personal Computers (PC) running ArcView. Many GIS developers are very familiar with the workings of ArcInfo and Arc Macro Language (AML), ArcInfo's programming language. Developers accustomed to developing tools and applications with AML frequently reuse or integrate tools from AML application to application using known programming technique and practices. Developers are now discovering new challenges while developing tools and applications with ArcView and Avenue, ArcView's object oriented scripting language. Many are finding that ArcInfo programming techniques and practices do not translate well to the ArcView development environment.
As ArcInfo grew and matured, developers started using in-house guidelines and standards when developing AML scripts. Esri provides one of the best example set of guidelines and standards in the ArcTools package. The AML scripts in this package defines a base framework by which other developers can integrate or reuse pieces of code. As ArcView becomes the default development platform for many developers, the requirement for a similar set of guidelines and standards increases. These guidelines and standards, as related to the development of individual tools or sets of tools that make up an application, are pieces of an "application framework."
ArcView development activities often focus on developing tools for inclusion into a single project file. When the need arises to reuse these tools, developers usually need to transfer these scripts for these tools from project file to project file. In most cases developers find themselves rewriting these scripts to properly fit into the new project environment. Using an application framework consistently among development activities can help avoid or limit the amount of integration when reusing scripts or developing new scripts.
The purpose of the framework outlined below is to support the integration of applications and individual tools specifically within the ArcView development environment by providing the organization and "hooks" to allow easier integration. This framework in particular will take into account the specific characteristics of the Avenue object oriented language and the ArcView project file convention. The goal of this framework is to provide a guide to the development of scripts for use in a single project. The concepts discussed in this paper are suggested methodologies based on several ArcView application development efforts. These concepts are by no means the only acceptable approach. This paper only suggests areas to consider in developing Avenue tools and applications.
The information in this paper originates from a request for information by a customer on how to direct multiple contractors in the creation of ArcView 2.X applications using a single user default project file. At the time this paper is being written, ArcView 3.0 is in beta release and includes new functionality not taken into account here. A brief discussion of these features occurs later in the paper.
This paper discusses concepts used in developing Avenue scripts for inclusion in ArcView applications. Primary distribution of these applications is through the use of the default project file. The concepts in this paper are founded on ArcView development activities involving sets of tools that make up an application as opposed to single tool development activities, but many of the concepts are directly related to both development environments.
What is an application framework? An application framework provides a common development philosophy that allows for the development of code that looks similar, acts similar, and that makes use of the application environment in a similar fashion. Using an application framework as a guide for script development allows the developer to set guidelines by which all script development should follow. In doing so, developers can avoid possible conflicts with other developers who will be integrating or building scripts for the same applications, thus avoiding possible runtime conflicts with other scripts.
Why use an application framework? There are several reasons why developers should use an application framework which includes: avoid limitations of one ArcView default project file, uniform guidelines for script development even between project files, and "hooks" for future development. The benefits of using an application framework include: reuse of scripts, easier integration of scripts into a single project file, consistent use of the user interface, and a basic level of organization for script development. This paper will focus applying an application framework in three areas: the ArcView development environment, the ArcView application infrastructure, and the ArcView user environment.
The ArcView development environment centers on the Avenue script and the ArcView Script document type. The script document allows a developer to create and test scripts prior to embedding them in a project file or default project file. When multiple developers create scripts they must do so from independent copies of ArcView with no script configuration management support. Knowing that each developer has their own unique naming and documentation style suggests that a common coding method should be used during development to avoid problems and inconsistencies when scripts are brought together to form an application. This section will focus on three areas: script naming, header, and comments.
The first level at which development activities can organize scripting efforts is at the script name. The script name fundamentally describes the script and its functions. The name of each native ArcView script uses the name of the document type it supports. The Esri development staff uses a naming convention that prefixes the document type, separated by a period, followed by the descriptive script name. This organizes all native ArcView scripts by document type, allowing easy access to document scripts. Developing a script naming convention for an application development activity helps developers organize scripts for easier access. The following are a suggested set of guidelines:
Naming modified system scripts is an issue that needs to be addressed by each development activity. If a developer adds several lines of code to a standard ArcView script during a development activity, it should be placed back into the system with the same name or rename the script and change the affected GUI to use the script with the new name. There is no easy answer. If the developer keeps the same ArcView name and places the script into a default project file, the modified script is run every time by every project. This can have disastrous results. If the developer modifies the name of the script, the developer needs to make sure that the GUI is modified to call the script. This means that the developer now needs to manage the GUI and make sure that it is created or modified and used at the appropriate time. The correct option depends on the development activity.
The script header serves an important role in the documentation of a script. The header describes the history of a script and its functionality (Example 1). The script header serves as method of communication between different developers on independent machines or as a method of communicating thoughts and ideas on a script to a developer who may need to work with it in the future.
The script header can be as simple or as complicated as required by a development activity. Companies and organizations should adopt a standard header for use within development activities. There are several base items that should be placed in a header section which include: script name, function, self, return, author, versions, and some form of script creation or modification date. Information like author, version, and script name provide basic documentation for the script. Other fields such as "Self" and "Return" document ArcView specific development information on items passed into and out of a script. If desired, other objects used by the script can be documented as well such as global variables, object tags, calling script and GUI items.
' Name: PROJECT.Shutdown
' File: shutdwn.ave
' Function: Common Shutdown script
'
' Self:
'
' Returns:
'
' Author: John R. Sawicki
' Version: 1.0 Date: 7/21/95
' Description: Initial Release
av.run("xyz.CloseSQLConnection",nil)
Example 1.
The script header in no way needs to be an inactive piece of text. In the example above, the header includes a field called "File." This field is used by a script management tool to name the export file for that script. This tool automates exportation of all script documents in the developers project file to a script directory. All developers on the development activity use this tool to export their script in order to create a new "default.apr" file.
Depending on the level of effort of the development activity, the header in combination with application developed script management tools can serve a more important role in the configuration management activity. As mentioned above, Avenue developers on independent systems have no real configuration management support. The benefit of developing and adding script management tools to the development environment include: helping to alleviate developers of task associated with script documentation, assuring consistency when handling and writing script documents, and helping to automate and manage scripts between several developers. ArcView currently does not contain any script management tools. These tools are fairly easy to develop, and with proper planning, can be useful during development.
Script documentation (comments) is an important part of any application development activity. However, script documentation is also the least practiced activity of application development. Documentation through comments not only helps the current developer build and modify a script by documenting functionality, but also assists other developers who may have to integrate a script within another application or may have to modify a script as part of the maintenance of an application.
Typing comments so they stand out from normal Avenue code is a key element to this practice. The current Avenue coding style uses a mixture of lowercase and proper case for typed Avenue commands. Distinctly typing comments in using a combination of blank lines and spaces with proper and upper case letters makes comments easier for the developer the type and read. Example 2 contains a suggested way of commenting text
' USE UPPER CASE WITH A BLANK COMMENT LINE TO
' DIFFERENTIATE SECTIONS OF CODE AND FOLLOW WITH A BLANK LINE
'
projectDictionary = av.GetProject.GetObjectTag
viewListDict = projectDictionary.Get("viewListDictionary")
'
' Use proper case when explaining in great detail the actions of a given part of code
' and separate with a blank comment line above and below and the comment block
'
indexList = viewListDict.Get("index")
Example 2.
As with the script header, companies and organizations should adopt and use standard guidelines for comments. These guidelines should produce comments that are easy to read, yet stand out from the surrounding Avenue code. Some developers find upper case text is "overbearing and hard on the eyes" while some developers find proper case and lower case text "insignificant and hard on the eyes." Clearly a middle ground needs to be adopted and used during development.
The application infrastructure is the foundation by which application scripts perform their tasks. In ArcView, script execution in most cases uses other ArcView objects such as global variables, objects tags, and the project startup and shutdown scripts. These objects, plus several others in ArcView, serve as resources for script development. Application development and integration activities need to manage these objects to prevent conflicts with other scripts. This section will discuss the use of the following objects in relations to application development: global variables, object tags, and application scripts.
The use of global variables in ArcView provides the developer with a way to store objects for future use and to pass objects among scripts. This functionality allows developers to process an object and to hold it in memory during that ArcView session. The use of global variables in an application can be tricky for several reasons which include: global variables are not persistent and are not saved to the open project file, the command "av.ClearGlobals" clears all global variables from memory, and the need to explicitly check for the existence of the global before referencing the variable in order to prevent script error (Example 3). A better way to maintain object persistency in an application is through the use of object tag requests. The use of object tags will be discussed later in this paper.
if (_xyz$bufferDistance.GetClass.GetClassName = "Nil" ) then
av.run("a.BufferSetDefault","")
end
Example 3.
If an application uses global variables, name the variables logically to prevent other developers or applications from overwriting them. Using a naming structure similar to script prefix structure provides an easy way to view and organize global variables.
Object tags provide an essential and powerful capability in Avenue development. The primary use of an object tag is to tag, or relate, one object with another. This allows developers to build relationships between objects. Object tags are persistent in the project file as long as the object that is tagged exists. Most, but not all Avenue objects have to ability the maintain object tags. In application development, the use of object tags can play a very important role in relation to the users developed application or in relation to ArcView.
In the Avenue object oriented environment, scripts use and create objects as needed. In some cases developers need to keep objects active during the ArcView session or during the life of the application or tool. Using object tags to maintain objects allows developers to save objects in places where they can be easily retrieved. Object tags by their nature form persistent relationships between two objects. For example, a script on the View document GUI starts a procedure to edit a pre-selected theme. This script can store, retrieve and use the theme or a clone of the theme from the view's object tag. As with any programming process there is a need to create, set, check, and manage object tags. There are advantages to using object tags to store objects which include object persistency and Avenue requests to find objects by their object tags.
In an application, the most powerful object to tag is the project object tag. By tagging the project, developers can store persistent objects of any type between project sessions. However, object tags only store one object. To avoid possible competition for the use of objects tags, consider attaching a collection object, such as a dictionary, to important object tags. This dictionary gives the developer room to attach multiple objects to that one object. At the project level, this dictionary can store and manage all project related objects. These objects can be a single object or a collection of objects. When planning integration between two applications or with multiple tool sets, it may be wise to have a dictionary tagged to the project that contains two or more dictionaries, one for each application or tool set.
The use of object tags serves a very important role in Avenue application and tool development. Planning the use and management of these finite resources before application development starts can avoid conflicts later in development. Properly setting up collection objects on object tags that will require more than one tag will support system growth without having to redevelop scripts.
Each project has one associated startup script and one associated shutdown script. Startup and shutdown scripts are useful in application development because they allow the application to properly start and close your application with the current ArcView session. Activities associated with a startup script may include: setting up variables, setting or retrieving objects from objects tags, starting ArcView services such as SQL connections or Inter-Application Communication (IAC) processes, and setting the user GUI environment. Activities associated with a shutdown script may include: setting or removing objects from object tags, and stopping ArcView services such as SQL connections or IAC processes.
As with object tags, projects only maintain one associated startup and shutdown script. Setting a flexible startup and shutdown scheme prior to development avoids future problems. Building a default startup and shutdown script that runs separate application or tool startup and shutdown scripts provides the developer with a method for integrating these scripts (Example 4). There is no easy way to predict the needs and conflicts of integrating startup and shutdown scripts. In building a generic and shared startup and shutdown script, developers create a modular environment that greatly supports integration of other scripts. Knowing and allowing for growth in this area is crucial for the subsequent maintenance and enhancement of an application.
' RUN APPLICATION XYZ STARTUP SCRIPTS
'
av.Run("xyz.ReadProjectDictionary",nil)
av.Run("xyx.SetUserGUIEnv",nil)
' RUN APPLICATION ABC STARTUP SCRIPTS
'
av.Run("abc.StartSQLConnection",nil)
Example 4.
The foundation of the ArcView user environment is the document. Each document uses a specific document GUI containing functions appropriate to the document type. Each GUI provides a constant user interface between document types. When modifying and using a GUI there are several key issues to look at including how to maintain a consistent look and feel and how to include large amount of menus, buttons, and tools on an already crowded interface.
The ArcView document GUI contains a menubar, buttonbar, and toolbar. The default document GUI from Esri contains all base ArcView functionality. Developers can modify these GUIs in any way desired by adding and removing functionality, and modifying the look or actions of a current the current ArcView functionality. First, developers should take care when modifying current ArcView functionality. Even simple changes to the base ArcView functionality may cause problems and confusion with users. Developers should also avoid confusing users with menu item labels, and button and tool icons that are similar to the ones currently used by ArcView. Developers should differentiate their own functionality with new icons and menu labels while still being consistent with the overall ArcView look and feel. "Similar but different" is the best rule to use.
When developers find that they need to drastically change the GUI or need to add more menus, buttons, and tools than ArcView will allow, they should consider using a toggle switch on the GUI to enable users to switch between interfaces (Example 5). This toggle switch allows the developer to maintain the base document GUI, and furthermore, add a relationship and a mechanism so the user can switch to other GUIs for the same document type. These GUIs can be advanced or novice versions of the normal document type, or provide functionality unique to the application. The toggle switch, which can be a button, menu item, or control key sequence, allows the developer to build separate GUI objects and allows the user to toggle the document GUI to them.
' Name: xyz.ToggleToolBar ' File: togtlbar.ave ' Function: Toggle tool bar GUIs ' ' Version: 1.0 Date: 4/7/95 ' DR Description: Initial Release if (av.GetActiveDoc.getGUI = "ViewGUI") then d ="UserGUI" else d = "ViewGUI" end av.GetActiveDoc.SetGUI(d) av.FindGUI(d).Activate
Example 5.
The objective when developing GUI objects and user interactions is to remain consistent with the current ArcView interface. In doing so applications and tools will be consistent with each other. Maintaining consistency in the look of the GUI and in the uses and wording of dialog boxes is an important factor in GUI development. There is no specific guideline that can easily be described in this paper, development activities should address and consider the user interface when planning and developing an application.
With the imminent release of ArcView 3.0, around the time of the 1996 User Conference, concepts and ideas presented in this paper will change and evolve. ArcView 3.0 includes several new development related objects and requests that will change the way ArcView development is done.
The first major addition to ArcView is the new Extension class, which is a subclass of the ODB object. Extensions provide the means by which developers transport and distribute Avenue code without relying on the use of the project file. The extension object includes several capabilities to install and uninstall objects such as scripts and GUIs during an ArcView application session. This functionality is the primary means by which developers will deliver Avenue based tools and functionality to users. Esri is using the Extension model as the basis for distribution of new additional software for ArcView. With the new release of ArcView, new functionality does not reside in the base copy of ArcView but instead is loaded and unloaded by the user as needed.
Also in the new release, Esri provides new capabilities for the creation and management of document GUIs (DocGUI) in Avenue, nicknamed the "Virtual Documents." With this new functionality, users and developers can create a customized instance of an ArcView document allowing for new and different functional documents types. These new instances reside in the standard ArcView project window.
These new capabilities, plus several other new Avenue requests,
will further strengthen ArcView as a development platform by allowing
greater customization of the base product.
The ArcView development environment is unique in many ways. The information available about this environment is still very limited. This lack of information may lead to some confusion among users and developers during application development. In the case of developers, this confusion can lead to development activities which are less productive than they can be Applying experience and knowledge gained in previous development activities in an application framework will help new development activities.
The information presented above is by no means a definitive application framework. It only provides a background from which developers can build their own application framework. The use of an application framework during a development activity increases the overall value of the development staff by increasing the reuse of Avenue scripts and tools developed. With the framework in place, scripts and tools developed by several users are easily integrated into an application making large development activities easier. Any application framework should provide a common coding structure and common users methodologies. In doing this developers have a guide by which the code they create is written in a standard modular and reusable fashion. Without the use of an application framework, developers are constantly trying to anticipate the works of other developers and how their code can coexist in a common project environment.
In the current ArcView development environment little can be done to avoid the need for integration, but providing a common development structure through an application framework can make the process of integration easier. With the new version of ArcView on the horizon developers need to address current development activities and plan how new activities will be done in the future.
John R. Sawicki
GIS Applications Engineer
TASC, Inc.
12100 Sunset Hills Road
Reston, VA 22090 USA
Telephone: (703) 834-5000
FAX : (703) 318-7900
Email: jrsawicki@tasc.com