|
The
file system data port provides a means for a zeroCode
UDM to access and modify files on the server. It
enables the designer to create UDM nodes associated
with files, and at run time, retrieves or modifies the
file data when the UDM is retrieved or submitted.
Given the full path name for a file, the data port
retrieves or stores the file's data.
|
|
|
|
From
the UDM's viewpoint, each file is thought of in terms
of its attributes:
|
| |
name,
a character string. This name is just eh file name, not
the full path of the file in the file system. |
|
size,
i.e., the number of bytes (an integer). |
|
kind
(directory or file). This value is a single character,
either 'd'
(if the file represents a directory) or 'f'
(if it is a plain file). |
|
time
of last modification |
|
content,
a byte block. |
|
contentMimeType,
a string containing the file's mime type (e.g., application/msword). |
|
|
Note
that only the name, kind and content attributes are
modifiable. The data port silently ignores attempts to
modify the other attributes. |
|
Data
port parameters
|
|
Ordinarily, one would
expect to use a single string as a file's full path to
specify the file completely. The file system data port,
however, requires two parameters: a path base and a path
offset. It uses the concatenation of these two
parameters as the full path. (More precisely, it assumes
that the first parameter specifies a directory and the
second an offset relative to that directory. So if the
first parameter does not end with a slash and the second
does not start with one, it introduces a slash between
the two.) The main reason for this organization is
security. It is frequently necessary to transmit such
parameters (via node values, say) as hidden fields in
HTML forms. If we had required a single parameter
specifying the full path name, then that path name would
be exposed to any end-user that views the HTML source.
This means that a potential hacker can acquire
information about the web server's directory structure,
and could use it as a launch point for an attack. With
the present structure, we can arrange for the path base
to be set up either as a literal value in the UDM or to
be retrieved from the site's configuration file via the
configuration parameters data port. Thus we need only
transmit path offsets in hidden fields, and this is much
safer.
|
|
|
|
Reading a (plain)
file |
|
To read a file, you
create a UDM node using the file system data port,
specifying the file's path name as its parameters. The
data port then reads the returns file's attributes. It
uses the file's extension to infer the file's mime type,
using a predefined mapping. |
|
Listing a directory |
|
You can use the file
system data port to read the list of files in a
directory, simply by creating a list (vector) node in
the UDM that uses the file system port. The parameters
for the data port must specify the full path name for
the directory to read. |
|
Creating and
modifying files |
|
To create a new file,
simply create a UDM node that uses 'add' mode, and to
modify the content of an existing file, create the node
using 'edit' mode. To add or modify a file's content,
you write the file's content attribute, either directly
or via a storage binding. You can also use the data
port's “append while writing” parameter to ensure
that new data gets appended to the file's existing
content. |
|
Creating a directory
|
|
You can also create new
directories using this data port. To create a directory,
you must specify 'add' mode for your UDM node, and the
character 'd'
for the node's kind
attribute.
|
|
|
