| Every file in a HyperContent project maps to a path pattern specified in one of three main element types in the project definition document: xml-doc, xml-doctype or resource-directory. These elements are discussed in more detail in the "XML Content" and "Non-XML Content" chapters; for now, it is important to note that each of these elements configures a unique class or instance of content, by mapping one path pattern to a semantic label and 0 or more forms of output. A path pattern might simply look like a literal path in the filesystem, such as
/index.xmlor, it might contain wildcards
/images/*When a wildcard occurs as the final character of path pattern, it represents a file; the file extension is not part of the pattern, as it will depend on the element which is being used to configure the content. When a wildcard is followed by a forward slash, it represents a directory name.
Every path pattern for a configured element must begin with a "/" to indicate the root of the repository; patterns are also used to specify includes, covered in a separate chapter, which is the only time you may leave off the leading "/" to specify a relative location. It is important that any paths representing directories end with a trailing "/", such as the base-url of an output filesystem (e.g. "http://hypercontent.sourceforge.net/docs/").
A forward slash "/" should always be used as the directory separator, regardless of the operating system in use.
An ExampleSay you want to define a Document Type "Faculty Bio"; you could specify its path at "/faculty/*". Then your repository could look like this:
/faculty/ If you wanted to also have a Document type "Faculty Course Listing" associated with the professor, you would want to organize them together in a directory. In that case, you would want the directory name to be the wildcard:
/faculty/*/bio.xmlWhich could make your repository more like this:
/faculty/ If you wanted to construct the output with links to a number of individual course pages, also associated with the professor, you could add a "Faculty Course" Document type with a path of "/faculty/*/*". This would allow you to create new courses only for faculty members that have already been created in the project. Your repository could then look like:
/faculty/ If you wanted to allow each professor to store graphics to present in their course documents, you could create a resource directory called "Faculty images" with a path of "/faculty/*/images/*" accepting content types image/jpeg and image/gif.
bio.xml johnqteacher /
/faculty/ In the Content Manager, users will only be presented with options to create new files in locations where only a single wildcard is left to fulfill. For example, you could not create a new "Faculty image" file at "/faculty/jimassistant/images/jimbo.jpg" without first creating "/faculty/jimassistant/bio.xml" or "/faculty/jimassistant/courses.xml".
bio.xml johnqteacher /
As you can imagine, this flexible system of defining paths can accommodate very deep and complex filesystems while maintaining a strict understanding of what kinds of data live in each directory. This controlled directory structure is essential to the power of XML includes, as data relationships are imprinted onto the very structure of the filesystem.