FAQDOCSDOWNLOADSGALLERYJA-SIG LogoSourceForge.net Logo
Overview
Getting Started
Using the Content Manager
Authoring Content
Developing Sites
Project Definition Files
Filesystems
Path patterns
Content Types
XML Content
RDF: Extensible Metadata
Dublin Core Metadata
VCard Metadata
XML Includes
XSL Transformations
Filters
Non-XML Content
Editors
Ignored Directories
Permissions
Navigation and Site Maps
Optimizations
Glossary
Bibliography
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.xml

/config/navigation/topnav.xml
or, it might contain wildcards
/images/*

/docs/*/*

/courses/*/index.xml
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 Example

Say you want to define a Document Type "Faculty Bio"; you could specify its path at "/faculty/*". Then your repository could look like this:
/faculty/
marybprof.xml
johnqteacher.xml
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.xml
/faculty/*/courses.xml
Which could make your repository more like this:
/faculty/
marybprof/
bio.xml
courses.xml
johnqteacher/
bio.xml
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/
marybprof /
bio.xml
courses.xml
m101.xml
m102.xml
johnqteacher /
bio.xml
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.

/faculty/
marybprof /
bio.xml
courses.xml
m101.xml
m102.xml
images/
m101Logo.gif
m102Logo.jpg
myportrait.jpg
johnqteacher /
bio.xml
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".

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.