In this topic
aims_simple application
This example application is titled aims_simple and is included with ArcIMS. Use an Image Service named SanFrancisco, which uses SanFrancisco.axl, which is located with the tutorial data. Running this example should produce a Web application that looks like the following screen shot:
For this example, you'll use the following files found in the WEB-INF folder:
faces-config.xml
The faces-config.xml file is used to connect the business objects that are part of the Web ADF and identify the appropriate ArcIMS service name, host name, and port number. Map.jsp contains the JavaServer Pages (JSP) tags to provide the rendering of the map application, such as a map and tools for working with the map. The data that is used to create this visual view is tied back into the data sources identified in the faces-config.xml file.
Context control
When you open faces-config.xml, the first managed bean you see is for the WebContext. While the context is a model tier 1 component, the context also acts as the manager for the other model tier 1 components. It connects the data sources to the controls and it coordinates among the controls when there is an action that requires a refresh. To enable this coordination, all the other model tier 1 components are registered with the context as managed attributes. These attributes (such as WebQuery) are stored in the attributes HashMap. This HashMap can also be used to add your own classes you want managed by the context or other arbitrary information, such as username, that you want associated with the lifespan of the context.
Inside the .xml file, each model tier 1 component is given a name to be used in the JSF framework, and the JSF expression language (EL) is used to refer to a managed bean listed later in the file.
In this example, a managed bean with the name map is stored under the key "map" as shown in the following code. Since the controls use the model tier 1 objects to access and manage their data, for each control on the JSP page, there must be an appropriate model tier 1 object registered with the context.
[Java]
< managed - property > < property - name > attributes < / property - name > <
map - entries > < map - entry > < key > map < / key > < value > #{
map
}
< / value > < / map - entry > < / map - entries > < / managed - property >
These tier 1 objects are loaded into memory when they're first used in the application. Therefore, if you leave an entry for a tier 1 object in the attributes list but don't add the tag to the page for the control, then it will not be instantiated.
The only other information in the context control is a list of the resources used in the application. There should be an entry for each data source the application uses for data. The syntax for each resource uses JSF-EL to reference a managed bean containing the appropriate connection information.
The following code indicates there is a managed bean named aims that references a connection to the service.
[Java]
< managed - property > < property - name > resources < / property - name > <
list - entries > < value > #{
aims1
}
< / value > < / list - entries > < / managed - property >
Declaring the resources
Each resource associated with the context needs a managed bean to handle the communication with that particular data source. For this example, you only have one resource that uses an ArcIMS service as shown in the following code.
[Java]
< managed - bean > < managed - bean - name > aims1 < / managed - bean - name > <
managed - bean - class > com.esri.adf.web.aims.data.AIMSMapResource < /
managed - bean - class > < managed - bean - scope > none < / managed - bean -
scope > < managed - property > < property - name > hostName < / property -
name > < value > localhost < / value > < / managed - property > < managed
- property > < property - name > port < / property - name > < value > 5300 <
/ value > < / managed - property > < managed - property > < property - name
> serviceName < / property - name > < value > SanFrancisco < / value > < /
managed - property > < managed - property > < property - name >
functionalities < / property - name > < map - entries > < map - entry > <
key > map < / key > < value > #{
aimsMap
}
< / value > < / map - entry > < / map - entries > < / managed - property >
< / managed - bean >
As with all other managed beans, the first three elements are the required elements for a bean: name, class, and scope. The AIMSMapResource class is the concrete implementation of GISResource for talking to an ArcIMS service. After these elements, you must declare the ArcIMS host machine to which you want to connect, as well as the port and the appropriate ArcIMS service. In this case, the server is called localhost, the port is 5300, and the service is SanFrancisco. Finally, a resource managed bean contains a HashMap that registers all the functionalities you want to expose on that specific resource.
The Web ADF provides functionality for all five of its data sources, each one with only the appropriate functionality. In this example, you are using only the map functionality. If you want to use another functionality, you can add a listing here and, where appropriate, a control and JSP tag to expose the functionality at the Web tier. The functionalities are declared using managed beans. Since adding new functionalities to a resource is an advanced tag, and to simplify faces-config.xml, the declaration of the functionalities has been moved to separate data source specific files. These files are located in the WEB-INF/functionalities folder.
User beans
You can write a user bean for each resource to which you want to connect. This bean holds the authenticating information appropriate to the resource. You can also reuse the same bean in several resources.
Other components of faces-config
The last two beans in the file are used to manage the Web ADF. The referenced bean is created internally to the application and is managed by the managed bean, which is named esriWebSession.
aims-functionalities.xml
The aims-functionalities.xml file declares the functionalities of the application. The Web ADF uses a consistent naming convention for the managed beans that expose functionalities. The ArcIMS functionalities are located in the JavaDoc Web ADF Reference. The managed bean name for each functionality is the source name in all lower case with the functionality name using camel case. For example, the ArcIMS map functionality class is named AIMSMapFunctionality, while the managed bean is named aimsMap. If you want a resource to appear in your map, you must declare the functionality with that resource as shown in the following code. The inverse is also true; if you want to use a resource but not all of its functionality, the only step required is to omit that unwanted functionalities from faces-config.xml with that resource.
[Java]
< managed - bean > < managed - bean - name > aimsMap < / managed - bean - name >
< managed - bean - class > com.esri.adf.web.aims.data.AIMSMapFunctionality < /
managed - bean - class > < managed - bean - scope > none < / managed - bean -
scope > < / managed - bean >
context-attributes.xml
The context-attributes.xml file contains managed bean declarations for all the tier 1 objects used in the application. This gives you the opportunity to set the server-side properties for each control. An example is the image format for the map. The following code shows the declaration for the WebMap tier 1 object.
[Java]
< managed - bean > < managed - bean - name > map < / managed - bean - name > <
managed - bean - class > com.esri.adf.web.data.WebMap < / managed - bean -
class > < managed - bean - scope > none < / managed - bean - scope > <
managed - property > < property - name > imageFormat < / property - name > <
value > PNG < / value > < / managed - property > < / managed - bean >
You are declaring a managed bean with the name map to be of class WebMap. Since its scope is set to none, the scope will be managed by its calling object; in this case, the context managed bean. After these required elements are set, the rest of the elements are settable properties for the WebMap class. These properties are considered server-side because they control the server processing of the map data. For example, whether or not to stream Multipurpose Internet Mail Extensions (MIME) data to the client is a server side property, while border color of the image is a client side property. There are a few properties of the map, such as height and width, that can be set at both the server and the client. For a complete list of server side attributes for each of the tier 1 objects, see the reference documentation for the controls.
Once again, you only need to declare managed beans for the actual tier 1 objects used in your application. Because the scope is set to none, declared but unused managed beans will not be instantiated.
Closing
The pattern followed in faces-config.xml is to wire together the pieces in model tier 1, declare the context and the other tier 1 pieces with which it will work, and establish which concrete data resources it will communicate with in model tier 2. You then add the rest of the pieces in tier 1 that are necessary to work with the context and their properties. After finishing with tier 1, the file moves to tier 2 where it creates a managed bean for each concrete resource used in the application and the functionalities exposed on each resource. Finally, there is the credential information for resources that require authentication.
To expose a data source at the Web tier, you need to consider the entire framework. In this example, you can start from the bottom. If you have an ArcIMS service, and you want to show its map in your Web application, you need to do the following:
- Declare your ArcIMS host site with a service such as GISResource
- Associate AIMSMapFunctionality with that resource
- Declare a WebMap in your application to use the functionality
- Associate the WebMap with the context, ensuring it participates in the Web ADF
- Place the appropriate tags on the JSP page
With the model tier 1 and model tier 2 wired together, you can build the view tier and connect it to the model tier.