As mentioned before, DataSplice views define rectilinear sets of data in an external data source. You can think of them similarly to tables in a database. However, depending on the SQL statement used to generate a view, the data might come from multiple underlying tables (joins, etc.).

Once the data is queried, any relational information from join statements is lost and the data is treated by DataSplice as if it had come from a single table. Hierarchical data is modeled using separate views and defining relationships between them.

The View Editor

Select the View -> Display Views menu item or toolbar icon to display the View Editor screen and the views available on the current server. As you can see, the views can be categorized in separate folders to make it easier to categorize the available items. Additionally, the Search Filter box can be used to quickly find a particular view if a large list is available.

New views are created using the Actions -> Create New View menu item. This displays a prompt with the following items:

View Name - Enter the name of the new, separating folder names with backslashes (Path\To\View)

Data Source - Specify which plug-in will control the view and provide access to the underlying data

• AdoNetDataSource - Most views will use this data source, which accesses information in relational databases using SQL statements.
• ScriptingDataSource - Creates views where the data is generated using JavaScript. This can be useful to support cases where the data required does not exist in any database.
• SimpleTableSource - This supports creating a matching table in the database that will store data for the view using the CampMaster Data Source.

Folders and Names

Use folders to organize the available views based on the functionality they provide. For instance, keep views for accessing separate applications in different folders.

Note that views can have the same name as long as they are in a different folder. It is highly recommended that the names be kept distinct for all views that a single user might potentially have access to. The path is typically not visible to the user, so this can reduce confusion.

However, this can be useful if different view versions need to be maintained for separate groups in some cases. For instance, you could have views Group A\Inventory and Group B\Inventory that support significantly different behavior in a way that is not possible to have in a single view.

The folder names are also used to organize the configuration documents saved in the storage folder. Note that views can be moved around and renamed by reorganizing the files in the storage folder, however the server must be restarted in order for any of these changes to take effect. Also, this often will break relationships and other references to the old view name.

User Masquerading

Often view functionality is tied to particular users and roles. The Administration Client can masquerade as a particular account to test functionality for various users and groups.

Select Actions -> Change User Masquerade from the menu to select the account to masquerade as. Select the desired authentication domain and user in the prompt. Depending on the functionality being tested the user's password may or may not be required. Anything that needs to use the password on the backend (for instance connecting to Maximo to commit changes through the MBO layer) will require the password to be entered. In addition, Actions -> Clear User Masquerade can be used to reset the masquerade settings.

Selecting Actions -> Display User Mode from the menu in the view preview will display extended information about the current user, such as the roles and available attributes, that are useful in diagnosing configuration issues.

This effects the Administration Client in a couple of ways:

• The text validator will show errors for expressions that reference attributes that don't exist. If the attributes are defined in a role, this can show spurious errors unless you masquerade as a member of that role.
• Previewing a view typically requires masquerading as a user that has the desired permissions being tested.

View Preview

The last option available in the Configuration Section drop list when a view is selected displays a fully-functional preview of the user interface that mobile users will use to interact with the configuration. This allows you to test and debug configuration changes without needing to switch back and forth between the Administration Client and a handheld.

Preview Mode - The display will either expand to fill the available space, or can be switched to emulate the screen size available on most handheld devices. Note that the Pocket PC mode is not a pixel-per-pixel representation of what the view will look like on a device given system font, screen resolution, and other hardware differences.

User Masquerade - This displays the account currently being used to masquerade as (if any).

There are a couple of notes that are helpful to keep in mind when working with the view preview:

• The preview acts as an online/connected session, so it might not be able to test all the functionality for offline configurations.
• Uncommitted changes are simply discarded when switching views or leaving the view preview.
  
• Typically the password must be supplied when masquerading to commit any changes made to the data.