Physical Storage
Locations in Deltanji represent stages or states in the workflow. When an object is transferred to a location, its components may also be copied or moved into a corresponding physical storage space. Where this is may vary depending on what type of component it is. For example, a text file, such as an HTML file, may be placed into a filesystem directory. However, a native Caché component such as a class may be placed into a namespace where it can be edited and executed. Alternatively, if the location is a library-view location, it may just be copied into the Deltanji repository.
The system manager is responsible for determining the physical storage spaces that each location maps to. A developer needs to be aware of what these are so that they can access the components.
Mapping Structures
To see a location's mapping structure, navigate to the location in the folders panel. When you click on it, the main panel should display information about the location. There should be a section that looks something like this:
Note: Although the screenshot above pictures relative paths being used for physical addresses, the use of relative paths is discouraged. The reason they have been used above is because the Deltanji environment that is pictured is the free 30-day evaluation kit. It uses relative paths so that the user is able to install the evaluation kit in a directory of their choice without compromising the physical storage mappings.
A mapping structure is a list of rules that Deltanji refers to when transferring an object to a location. In the image above, you can see 4 rows. When processing the transfer, Deltanji compares each of the objects' components with each mapping rule in order. In this case, it checks if the component is a text file with a .php extension. If so, it stores the component in text format at a physical address which is a directory: \pages\php. If the component does not meet the criteria, Deltanji compares it to the next rule. This tests to see if the component is a text file. If so, it stores it in text format at the directory \pages. The third rules checks to see if it is a binary component. Finally, if it matches none of the preceding criteria, Deltanji treats it as an M-specific component-type, and stores it in M format in the namespace VCM-DEV1.
For this particular location, this would be the outcome if several varied components were transferred to it:
| MAC.dbconvert | BIN.logo.png | T.formsubmit.php | T.readme.html | |
|---|---|---|---|---|
| T.*.php |
|
|
|
|
| T.* |
|
|
|
|
| BIN.* |
|
|
||
| * |
|
The following diagram demonstrates the mapping structure:
Working Location and Library-view Location Mapping
The mapping structure example given above would create a working location. This can be seen by the fact that components are stored at accessible addresses in an editable and executable format. A library view location, however, maps all of its objects' components to the library, from which they cannot be run.
The mapping structure for a library view location, therefore, looks like this:
| Component Mask | Storage Format | Physical Address |
|---|---|---|
| * | L | VCM-LIBRARY |
For more information about working and library-view locations, see the article on location types.
When working with binary and text files associated with a CSP application, see the article on CSP-relative file addresses.
See Also: Locations, Components, Managing Physical Storage, Managing Locations, Location Types