Mounting the Text Class Collection Online
From DLXS Documentation
Main Page > Mounting Collections: Class-specific Steps > Mounting a Text Class Collection > Mounting the Text Class Collection Online
These are the final steps in deploying an Text Class collection online. Here the Collection Manager will be used to review the Group Database. The Collection Manager will also be used to update the Collection Database for workshoptc, including setting up the collection for dynamic browsing. Finally, we need to work with the collection map and the set up the collection's web directory.
Contents |
[edit] Review the Groups Database Entry with CollMgr
One function of CollMgr allows the grouping of collections for cross-collection searching. Any number of collection groups may be created for Text Class. Text Class supports a group with the groupid "all". It is not a requirement that all collections be in this group, though that's the basic idea. Groups are created and modified using CollMgr. For this workshop, the group "all" record has already been edited to include the workshoptc collection. Take a look at the record to become familiar with it.
http://username.ws.umdl.umich.edu/cgi/c/collmgr/collmgr
You are the DLXS administrator of your local collections.
We won't be doing anything much with groups, but you can add your workshoptc to the Sample group, if you'd like. Be sure to release the group to production if you want any changes to be available in your interface.
[edit] Review the Collection Database Entry with CollMgr
Each collection has a record in the collection database that holds collection specific configurations for the middleware. CollMgr (Collection Manager) is a web based interface to the collection database that provides functionality for editing each collection's record. Collections can be checked-out for editing, checked-in for testing, and released to production.A collection database record for workshoptc has already been created and we will edit it. In general, a new collection needs to have a CollMgr record created from scratch before the middleware can be used. Take a look at the record to become familiar with it.
http://username.ws.umdl.umich.edu/cgi/c/collmgr/collmgr
Again, we need to release the collection to production to make our changes available.
For more information, see Collection Manager Field Descriptions
[edit] Configure the Collection for Dynamic Browsing Using CollMgr
Dynamic browsing is a feature introduced in DLXS release 12 and revised in release 13. Adding dynamic browsing to a collection is a matter of simple configuration in CollMgr and then running a script on the command line to populate the browse tables with data to facilitate browsing.
Collmgr field: browseable
To enable browsing, the browseable field must be set to "yes".
Collmgr field: browsenav
The browsenav field must have a value of 0, 1 or 2. Small collections should use 0. Medium collections 1. Large collections 2. This is the number of layers of browse tabs you want for the collection. 0 means that all the items are on one page -- no tabs. 1 means you have one layer of tabs with the letters of the alphabet, and 2 means you have two layers of tabs -- one for a letter, and another for the two-letter subdivisions under it.
Collmgr field: browsefields
browsefields holds the list of fields you would like to be browseable. This list is used to prepare the data for browsing, and also to present browsing options to the user. Currently, author, title, and subject are the canonical Text Class browse fields. You will need fabricated regions of mainauthor, maintitle, and subject to support browsing. A quick XPAT query of our workshop collection shows we don't have a fabricated region subject but we do have region TERM with subjects in them. We could add subject browsing but would need to do some work to support it.
Now that we are finished updating CollMgr, we need to release our collection to production.
With the above fields properly configured and CollMgr released, the updatebrowsedb.pl script can be run. It populates the ItemColl, ItemBrowse and ItemBrowseCounts tables with information from the collection's data dictionary. You should use the "wrapper" shell script provided in the same subdirectory, ub .
cd $DLXSROOT/bin/browse
./ub -C text -c workshoptc -h pilsner.umdl.umich.edu -r production
More Documentation
For more information, see Setting up Dynamic Browsing.
[edit] Make Collection Map
Collection map files exist to identify the regions and operators used by the middleware when interacting with the search forms. Each collection will need one, but most collections can use a fairly standard map file, such as the one in the sampletc_utf8 collection. The map files for all Text Class collections are stored in $DLXSROOT/misc/t/text/maps
Map files take language that is used in the forms and translates it into language for the cgi and for XPAT. For example, if you want your users to be able to search within chapters, you would need to add a mapping for how you want it to appear in the search interface (case is important, as is pluralization!), how the cgi variable would be set (usually all caps, and not stepping on an existing variable), and how XPAT will identify and retrieve this natively.
The first part of the file is operator mapping, for the form, the cgi, and XPAT. The second part is for region mapping, as in the example above. There is an optional third part for collections with metadata applied bibliographically, such as genre categories.
If you want to make a map file specifically for your collection (because you want to change the values in pulldown menus, perhaps), you need to make a copy of the existing map used and alter the values in the newly-copied map file, and then change the values in collmgr to refer to the new map and the new values.
cd $DLXSROOT/misc/t/text/maps<br>cp sampletc_utf8.map workshoptc.map
In DLXS post release 10, the map must have a mapping for the SYNTHETIC value ID. To facilitate sorting, the system must be able to assign one ID uniquely with each text.
<label>unique item identifier</label> <synthetic>ID</synthetic> <native>region id</native> <nativeregionname>id</nativeregionname> </mapping>
Mappings are also needed for maintitle, mainauthor, and maindate (if the latter are applicable).
More Documentation
[edit] Set Up the Collection's Web Directory
Each collection may have a web directory with custom Cascading Style Sheets, interface templates, graphics, and javascript. The default is for a collection to use the web templates at $DLXSROOT/web/t/text. A collection specific web directory may be created, and it is necessary if you have any customization at all. For a minimal collection, you will want two files: index.html and textclass-specific.css.
mkdir -p $DLXSROOT/web/w/workshoptc cp $DLXSROOT/web/s/sampletc_utf8/index.html $DLXSROOT/web/w/workshoptc/index.html cp $DLXSROOT/web/s/sampletc_utf8/textclass-specific.css $DLXSROOT/web/w/workshoptc/textclass-specific.css
As always, we'll need to change the collection name and paths. You might want to change the look radically, if your HTML skills are up to it.
Try It Out
http://yourworkshopvirtualhost/cgi/t/text/text-idx http://username.ws.umdl.umich.edu/cgi/t/text/text-idx
[edit] Customizations
Now, suppose you want to change a few things. Perhaps you want to change the word "Availability" to "Rights" in the ToC view. You may ask yourself, "How do I change this? I don't even know where this comes from!" Just as search form labels are set in the collmgr and the mapfile used by the collection, text labels are set in the langmap. (But grepping in the $DLXSROOT/web/t/text directory is always a good initial strategy for interface changes, if you haven't memorized every detail of DLXS yet.)
If you want to change this label for all Text Class collections, you can edit the page in the class directory. If this change is only relevant to one collection, you will need to make a langmapextra file and put it in the collection web directory. In my /l1/workshop-samples/sooty directory, there is a langmapextra.en.xml file that you can place in your $DLXSROOT/web/w/workshoptc directory.
<ColLookupTables>
<Lookup id="headerutils">
<Item key="headerutils.str.22">Rights</Item>
</Lookup>
</ColLookupTables>
You might also want to change the color scheme for the navheader bars, as Suz discussed earlier. You could edit the textclass-specific.css that we copied over (changing the td.mainnavcell background-color and the .navcolor) to whatever color you choose, or you could replace the textclass-specific.css with the version in my /l1/workshop-samples/sooty directory, changing these to some particularly muted shades of purple.
/* STYLES FOR NAVIGATION AND MENUS */
td.mainnavcell {
background-color: #A2A0AB;
padding-left:20px;
padding-right:20px;
border-bottom: 1px solid #666666;}
.navcolor { background-color: #8A7B90; }
Finally, you could change the handling of low-level encoding elements. If we do a few XPAT queries, we'll see that there are a lot of FOREIGN elements, with language codes. If we grep in $DLXSROOT/web/t/text for FOREIGN, we'll see it appears in text.components.xsl, but the values just get passed through with no additional styling. If we want to give it a style, we can add a local text.components.xsl with a template for FOREIGN. There is a version in my /l1/workshop-samples/sooty directory that you can copy to your $DLXSROOT/web/w/workshoptc directory and use as-is, or adapt to your XSLT abilities permit. The template below italicizes the content of the FOREIGN element, and then follows it with the expanded version of the LANG attribute language code.
<?xml version="1.0" encoding="UTF-8" ?> <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:func="http://exslt.org/functions" xmlns:dlxs="http://www.umdl.umich.edu/dlxs" extension-element-prefixes="func" exclude-result-prefixes="func dlxs"> <xsl:import href="../../t/text/text.components.xsl"/> <xsl:template match="FOREIGN"> <span class="rend-i"><xsl:value-of select="."/></span> <xsl:if test="@LANG='fle'"><xsl:text> [Flemish] </xsl:text></xsl:if> <xsl:if test="@LANG='fre'"><xsl:text> [French] </xsl:text></xsl:if> <xsl:if test="@LANG='ger'"><xsl:text> [German] </xsl:text></xsl:if> <xsl:if test="@LANG='gre'"><xsl:text> [Greek] </xsl:text></xsl:if> <xsl:if test="@LANG='hu'"><xsl:text> [Hungarian] </xsl:text></xsl:if> <xsl:if test="@LANG='it'"><xsl:text> [Italian] </xsl:text></xsl:if> <xsl:if test="@LANG='lat'"><xsl:text> [Latin] </xsl:text></xsl:if> <xsl:if test="@LANG='sp'"><xsl:text> [Spanish] </xsl:text></xsl:if> </xsl:template>
Note that this is just one template, not the entire text.components.xsl copied over. The class-level version is imported, and this FOREIGN template overrides the default one.
Back to the browse issue for a moment. Since subject browsing is available, and we know we have subject terms in our collection, we will probably want to add this functionality. So what do we need to do?
- First, we go back to CollMgr and add subject to the browsefields. Remember to release the collection to production.
- Next, we return to $DLXSROOT/bin/browse and rerun the updatebrowse.pl command.
- So, we have a link to subject on the browse page and subjects in the browse table. If we click on the "subject" link for our collection, though, we'll get an error.
- The browse script is hardcoded to look for the TERM element in the HEADER. Now we need to make this region available to the rest of the interface. The simplest method would be to add it to the collection map:
<mapping> <label>subject</label> <synthetic>SUBJECT</synthetic> <native>region TERM</native> <nativeregionname>TERM</nativeregionname> </mapping>This will work if the only TERMs you have are in the HEADER. Otherwise, you'll need to fabricate a region for subject and map that in the map.
