Configuration is a way to easily change PlanTest operation by modification of specific XML files, which may be on the local machine or on shared network resources. Configuration can be performed on several levels to adapt to specific site requirements and systems, and to provide an optimal;experience for various groups. There are three basic levels of configuration:
| Abbreviation | Description |
|---|---|
| CSS | Cascading Style Sheets |
| js | JavaScript |
| PT | PlanTest |
| PTd | PlanTest desktop |
| PTs | PlanTest server |
| XCF | XflowConfiguration File |
| XSTL | eXtensible Style sheet Language Transformations |
| XML | Extensible Mark-up Language |
PlanTest is at heart a decision support system. It supports checklist and automated analysis approaches. Given the diversity of cadastral systems, it was designed from the beginning to be deeply configurable. The configuration of PlanTest, both desktop and server, can be simple or complex, depending on the situation and goals. Configurations can also be easily switched at the application level to support various work groups or user roles. Much of this ability lies in the function of a single configuration file, the XflowConfiguration.xml file (XCF).
PlanTest based examination can consume several varied data sources, employ custom workflows, representation profiles, tools and analysis to produce purpose driven outputs. These resources may be organized in a single folder on a local or network drive, as custom services, or as distributed resources. The XCF is used to allow straightforward updates and additions of resource addresses.
A registry key defines the standard install location of the XCF. To enable flexible site testing, a second registry key points to a location where non-admin level staff can modify XCF settings during business group testing. There may be any number of XCF profiles throughout an organization, each for a different purpose or team.
Another key configuration file is he PlanTest.exe.config file located in the install bin folder, which can be used to configure the application for IT administration and network configuration. It is typically preconfigured for the jurisdiction and it is not necessary to modify its settings.
The solution architecture supports:
The standard hierarchy of configuration files is:
The locations of most resources are contained within a single XML file, the XCF. The location of the XCF is set via the registry. Seaconis can also customize the install location by request.
Two main configuration files are typically installed in C:\Program Files (x86)\Seaconis\PlanTest\site folder: the XCF and the Jurisdiction.xml configuration file. The XCF is expected to be modified by the customer.
The jurisdiction file sets key properties identifying the jurisdiction and specific high-level custom windows and controls. The jurisdiction file should not be modified on-site.
The default configuration is usually created during the development of a site-specific adaptation to a jurisdiction, and is installed as requested by the customer. The default assumes all customization files are located within a standard hierarchy of folders.
On any particular machine, switching out configuration files can be useful to support diverse applications of PT. In Seaconis development, we use a command file to switch between jurisdiction customizations to facilitate the testing of changes to core PT code on jurisdictional adaptations. Each client site has an install/setup package that packages core PT assemblies and jurisdictional assemblies.
At Seaconis, we have a Q/A install that includes all assemblies for all sites. By switching the XCF and jurisdiction files, we can restart PT as any site or configuration.
The same process can be used by any client to switch between testing and production services, or between completely different group data feeds, workflows, tests, reports and appearance.
The XCF has a simple XML schema specific to PlanTest. It may change over time, but only through addition of new elements. The XCF contains standard elements for application paths that are required, as listed below. However, any one of these might also be replaced by a deeper site-specific customization allowing a different solution. Service endpoints are the most common second class of elements, and these are always specific to a jurisdiction or site. The name of the service elements generally reflects the nature of the service. In NSW, there are several services, whereas Singapore has a single service with many service requests.
The following fictitious XCF shows the standard elements for resource paths. Elements with URL in the name are always custom locators that can be used to change the touchpoint of the site services.
<?xml version="1.0" encoding="utf-8"?>
<SitePaths
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<layersPath>C:\mySite\Layers</layersPath>
<examsPath>C:\mySite\Results</examsPath>
<xmlsPath>C:\mySite\Config</xmlsPath>
<schemaPath>C:\mySite\Schema</schemaPath>
<docsPath>C:\mySite\Documents</docsPath>
<themesPath>C:\mySite\Themes</themesPath>
<templatesPath>C:\mySite\Templates</templatesPath>
<workflowsPath>C:\mySite\Workflows</workflowsPath>
<pinkyURL>https://maps.global.gov.zz/ePlan/services/Pinky</pinkyURL>
<brainExamURL>http://every-night-same-thing:7804/brainexam/v1</brainExamURL>
</SitePaths>
Standard PTd path elements. PTs does not currently use the UI resources, but the XCF is generally kept consistent between PTd and PTs uses.
Future needs for any setting or configuration are handled by creating new elements as needed. It’s really just a key/value list.
Users can create multiple application layouts and settings to match particular workflows or tasks. These are called ‘Layouts’, and can be named and manage via the Options menu and its sub-menus. The selected options for UI behavior
These are managed within the AppData\Local\Seaconis folder by PTd. Each layout is comprised of a file pair, one which holds the windows layout and a second that holds all other user settings. They are read and written together. Although serving a function for a specific user, they can be copied and installed as part of a site customization.