|
|
The Berkeley Web Template EAD package is a hierarchical set of configuration files consisting of a "master" template containing templates and configurations common to all sub templates, and multiple sub templates containing configurations and templates unique to individual repositories or types of EAD files. The division of what sort of information goes in which file is arbitrary. Information currently in the master template could also go in the sub templates and information in the sub templates could also conceivably go in the master template. The division of configurations and templates is subject to your best judgement. I have created configuration files where the master file was largely blank and almost all of the information was contained in the sub template, and vice versa.
The template script first reads the master cfg file, adds its information to a configuration data structure, then reads the sub template and adds its information to the same structure. In other words, just like the food on your dinner plate, whether the information is in the first file or the second, it all eventually ends up in the same place. If configuration information is repeated in the second file it will replace or overwrite that already gotten from the first file. This is a useful feature. You may choose to put information which is usually common to all sub templates in the master file, but also place it in a few sub templates where it may differ. The only piece of information which is required in the master template is the TemplateDir parameter at the very top, telling the program where the sub templates are located. The rest of the master file could conceivably be blank.
I have organized the information in the EAD package in a way that I felt was easiest to customize on a basic level and also in a way that was the least confusing. This is absolutely not the only way this information can be organized, but I tried my best to make it as easy and clear as possible.
I have also struggled to factor out the most confusing features. As a result I have made the master ead.cfg template very confusing and difficult to understand, but the benefit is that the sub templates are relatively clear and easy to understand. This guide will focus mainly on modifying the sub templates and leave for another future guide the details of the master template and advanced customization techniques.
The repository-level configuration file is divided into 5 parts:
- Form field default values and miscellaneous variables (in [Global Template Variables])
Form field default values are the text that is supplied within a particular form field. This is appropriate for text that is *usually* the same from finding aid to finding aid, but it appears in the form field so that users may modify it if necessary before clicking Submit.
- EAD-encoded boilerplate sections (in the various [Template ...] sections)
This is appropriate for markup or text that is *always* the same for finding aids in a particular repository. It is EAD encoding that is inserted into the final markup which users may not modify. Information such as the name and address of the repository are good candidates for this section. They vary from repository to repository but within an individual repository they never change.
- A decorative institutional seal (in [Form RepositoryLogo])
This is the name of the repository and a logo that appears at the top of the form, in HTML. It's just there so that users may know immediately which template they are working with, and it's pretty.
- The form textfield and formfield selectors (in [Form Content] and [Form Toc])
This is the section where you "plug in" the various form fields each repository needs for its finding aids. You would modify this section if, for example, your repository needs to add a text box for <appraisal> or other additional EAD tag your repository uses.
- The final EAD XML markup template (in [Template _DEFAULT])
This is the final XML EAD output markup. This is a good candidate to remove from the sub template and place in the master template, making maintenance and changes to local EAD standards easier to implement. However I have found that often repositories insist on certain local encoding quirks, e.g., a specific order of elements, thus I reluctantly include it in the sub configuration file rather than the master file.
We'll assume your template package is correctly installed and calling up the
url:
http://your.servername.edu/cgi-bin/template/ead/generic brings
up the form correctly and clicking the submit button generates EAD XML markup. Make
a copy of generic.cfg and name it something appropriate for the department or type
of finding aid you want to customize, e.g., mss.cfg or manuscripts.cfg or something
like that. Open the new file in a text editor.
Change these values to change the default values supplied in the corresponding HTML form. The [Global Template Variables] section also includes miscellaneous text values that are usually changed on an institutional basis which I have placed at the top of the file for clarity and easy access. Following is a "crosswalk" mapping the appropriate parameter to the corresponding form element to the final EAD markup.
DEFAULT_ACCESS maps to the EAD element <accessrestrict>
DEFAULT_RIGHTS maps to the EAD element <userestrict>
DEFAULT_PHYSLOC maps to the EAD element <physloc>
DEFAULT_LANGUAGE maps to the EAD element <langmaterial>
DEFAULT_AUTHOR maps to the EAD element <author>
A few other miscellaneous text variables are available in [Global Template Variables] that don't map to default values in form fields. They are here simply because we have found it convenient to customize them for our particular EAD projects. You may choose to delete some of them or add new ones of your own.
TEMPLATE_TITLE does not map to an EAD element. It is simply
the title that appears in the browser's title bar. More usefully, it is also
the text under which most browsers list user bookmarks.
UNITTITLE_LABEL maps to the @label attribute of the EAD
element <unittitle>
REPOSITORY_CODE maps to <unitid> @repositorycode attribute
Global Template Variables are simply text values which you define in one place and invoke anywhere in any of your cfg files. The format is a variable name which must consist only of uppercase letters, numbers, or an underscore, followed by one or more spaces, then the constant text you are defining. Invoke them by enclosing the variable name in curly braces, e.g., {VARIABLE_NAME} and inserting them anywhere in any of your cfg files.
 UNITTITLE_LABEL is invoked in [Template _DEFAULT] |
 DEFAULT_ACCESS is invoked in [Form BasicInformation] |
The "boilerplate" text in Templates and Froms is similar to [Global Template Variables] in that it is defined in one place and then invoked elsewhere in your templates. Generally the boilerplate text is more complex than Global Template Variables, it usually contains markup and is layed out in multiple lines. Many things that can be defined as a Global Template Variable could instead be defined as boilerplate text (in a [Template ...] or [Form ...]section). It is largely a matter of taste and convenience.
[Template ...] sections can only be invoked within other [Template ...] sections and [Form ...]'s can only be invoked within other [Form ...] sections. The template program consists of two distinct steps, first the HTML form is generated, and then, after the user clicks submit, the XML markup is generated. The HTML code which generates the initial form is always found in [Form ...] sections and the final markup generated after the user clicks Submit is always found in [Template ...] sections.
Invoke both templates and forms by placing their name in curly braces preceded by an '@' sign, e.g., [Template PublicationStmt] is invoked with {@PublicationStmt}
|
UNITTITLE_LABEL is invoked in [Template _DEFAULT] |
DEFAULT_ACCESS is invoked in [Form BasicInformation] |