Workspace: Paths, Projects, Entities

Documentation home

 

Workspace. 1

Project 1

Entity Object 1

Paths 1

 

See also: Entity Relationships

Workspace

The workspace is a folder where all objects created in the studio are saved, and a workspace is required by both Verj.io studio and server components. In the studio the workspace is selected when the studio is started and can also be changed at any time by selecting File > Switch workspace from the menu. For a Verj.io server, the workspace is configured in the workspace.properties property file in folder ebaseConf using the Server Administration Application, and all objects are loaded from that workspace.

 

When developing, it is important that both the studio and server components are configured to use the same workspace.

Project

Within the workspace, work is divided into projects and a project is the only thing that can be created at the top level of the workspace – this is also the only place where a project can be created. A project is an important organisational unit within the Verj.io system: all objects within a project are automatically accessible to any other objects in the same project e.g. a script at path MyScripts/Script1 within the project is available to a form at path MyForms/Form1. Projects can also be linked which makes all objects within these additional projects available.

Entity Object

Anything that can be created in the studio tree (with the exception of folders) is an entity object. This includes forms, components, workflow processes, scripts, lists, resources, images, style sheets etc. Entity objects must be created inside a project.

Paths

All relationships between entity objects are implemented using paths where each path is the relative path from the root of the project. For example in the following project..

 

 

form Product_Edit has a before form event that runs script InitializeProduct – the path to this script is /Scripts/InitializeProduct.

Within form Product_Edit field ProductCode uses the ProductCodes list– the path to this list is /Lists/ProductCodes.

 

This is all fairly straightforward, but it can become more complicated when additional projects are linked. If we extend this example to add another project MySharedProject:

 

 

Now Form Product_Edit can use the Product resource and the path will be /Resources/Product. Note that the project name does not appear in this path. This means that the ProductCodes list in MySharedProject is effectively inaccessible from any form in MyProject – it would have a path of /Lists/ProductCodes but a list with this path already exists in MyProject and this will be found first.

 

Recommendation: to avoid confusion, it is recommended that a naming convention is used that provides unique path names, particularly when projects are shared between multiple applications. In the example above, everything in MySharedProject could be placed within a Shared folder at the root of the project and then all paths will start with this:

 

 

Then the path to the ProductCodes list is /Shared/Lists/ProductCodes and does not clash with the list in MyProject.