Files of any kind are allowed to be uploaded and stored in the database of the application, for later retrieval. This service is called the Application Resource Store. Once a file is uploaded, it no longer exists as a file, but as the value of a field in a database record. This database record is referred to as a resource. By constructing and resolving the appropriate path, a renderer plug-in can access property values from Java properties resources uploaded to this store.
The path form is a little different from the paths used for general properties files resources on the classpath, as it accommodates other path forms that are not supported in the custom renderers within the Cúram application. Also, as these are no longer properties files, there are differences in the way the resources are identified. Properties resources are loaded to a local cache when they are requested. The cache stores the properties in a form that optimizes locale fall-back operations and reduces memory usage through de-duplication, so the individuality of the original resources is lost. However, this results in an efficient system that is a good alternative to classpath-based properties resources, particularly where resources may need to be modified at run-time.
The path is created by extending the prefix path defined by ClientPaths.APP_PROP_RESOURCE_PATH. The extension adds a single step. The selector of the step is the name of the resource and a single predicate contains the name of the property key. The resource is identified using the name assigned to the resource when it was uploaded to the resource store. For example, if an administrator uploads the file PersonDetails.properties to the resource store and names the resource PersonDetails.properties, then that is the identifier that must be used. The .properties name suffix (which is not a file extension, as a resource is not a file) is not added or removed by the system and must be used as the identifier of the resource. The name could be set to just PersonDetails, without any suffix, but adding the suffix may help to make the type of the resource more readily identifiable from its name when administering the resource store. Either way, the resource identified in the path should match the resource name in the resource store exactly. An example of the construction of a path to request the age property from the resource store resource named PersonDetails.properties is shown below.
Path agePath = ClientPaths.APP_PROP_RESOURCE_PATH
.extendPath("PersonDetails.properties[age]");
String ageLabel = context.getDataAccessor().get(agePath);
As with general properties resources, only the get method is supported when accessing general properties resources. If no such property can be found, the get method will throw a DataAccessException.
Where multiple properties resource values are required, the path to the resource can first be created with an empty predicate and then the value of the predicate can be set again and again using the applyIndex method of the Path interface. This method returns a new path each time, it does not modify the existing path. The index value is used to set the value of the first empty predicate encountered in the path. This is shown below.
Path dtlsPath = ClientPaths.APP_PROP_RESOURCE_PATH
.extendPath("PersonDetails.properties[]");
DataAccessor da = context.getDataAccessor();
String ageLabel = da.get(dtlsPath.applyIndex("age"));
String dobLabel = da.get(dtlsPath.applyIndex("date.of.birth"));
String nameLabel = da.get(dtlsPath.applyIndex("name"));
String addressLabel = da.get(dtlsPath.applyIndex("address"));
The locale fall-back operation depends on all the resources in the sequence having the same name. When resolving properties using the local fall-back mechanism, the CDEJ does not modify the name of the requested resource, it only changes the value for the separate locale field in the resource store record. This differs from the way the java.util.ResourceBundle API creates new file names when searching for locale fall-back resources. When a resource is uploaded to the store, both the name and the locale should be specified separately through the administration interface. If the files PersonDetails_en_US.properties and PersonDetails_es.properties are uploaded, the administrator should assign the same name PersonDetails.properties (or just PersonDetails, if preferred) to both resources, but set the separate locale field value to en_US and es, respectively. If no locale is specified, then the resource is treated as the ultimate locale fall-back resource, just as the ResourceBundle API would treat a properties file with no locale code appended to its name.