You can set your server to check access permissions before displaying search results (through the Agents & Search|Search Configuration form discussed in "Configuring the search parameters"). When this is set, before returning the results of a search query, the server checks a user's access privileges and challenges the user to identify themselves before displaying any results.
Mapping URLs
When users search through a collection's files, the documents that are returned as search results use a partial URL, called a URI (or Uniform Resource Identifier), to identify them. This is a security feature that prevents users from knowing the complete physical pathname for a file. A URI is set up by mapping a URL to an additional document directory.
For example, if the path for a file is server_root/Docs/marketing/bizplans/planB.doc
, you could set up a mapping that prevents users from seeing all but the last directory by defining a URL prefix of plans
and mapping it to server_root/Docs/marketing/bizplans
. From then on, users need only type /plans/planB.doc
to locate the file. For more information, see Chapter 4, "Managing server content."
The Enterprise server provides four default mappings:
/
--the primary document directory (sometimes called the document root), which initially maps to server_root/docs
/search-ui
--the directory for most of the search interface files/webpub-ui
--the directory for most of the Web Publisher interface files/publisher
--the directory for most of the Web Publisher files, which includes the online Web Publisher help filesplans
.
C:/Netscape/SuiteSpot/Docs/marketing/bizplans
.
Note
Once you create a collection based on an additional document directory, you
cannot change the URL mapping or the collection's entries will target the URL
mapping to the wrong physical file location.
Deciding which words not to search
In the server_root/plugins/search/common/english
directory, there is a file named vdk20.stp
, which contains words the search engine does not index or search against in the English language. These are sometimes referred to as stop words or drop words and typically includes such words as at, and, be, for, and the.
For languages other than English, this file is in the directory for that language. This file applies to all collections in the chosen language. You can use a text editor to add or delete words you don't want the search engine to index or check against during a search.
Turning search on or off
You can turn search capabilities on and off for your server. Turning search off for a server where users do not use this function can improve server performance. You may also want to turn off the search function at certain times when you know the server will have heavy traffic, reserving this function for times when traffic is lighter.
If you turn it off, the search plug-in is not loaded when the HTTP server starts up. The default is for search to be turned on. To turn off the search function, use these steps:
You can turn search back on with these steps:
Configuring the search parameters
As server administrator, you can set the default parameters that govern what users see when they get search results.
To configure search parameters:
Title
tag. The typical default is (Untitled), which appears in the search results page for HTML files.
Configuring your pattern files
Pattern files are HTML files that define the layout of the text search interface. You can associate a pattern file with a search function and a set of pattern variables to create a specific portion of the interface. In the pattern file, you define the look, feel, and function of the text search interface. Pattern files use pattern variables that you can use to customize background color, help text, banners, and so on. In some cases, the values are pathnames to the files that contain the actual text and graphics that these variables represent; in other cases, the values represent text and HTML.
You can use the default pattern files, or you can create your own customized set of files and point to them from here. See "Customizing the search interface" for more information about how to change the user interface.
Configuring manually
The search function examines several configuration files to determine how search is configured on your server. These files define system settings, user-defined variables, and information about your search collections. You normally change this information through the Server Manager's Agents & Search forms, but you can also modify the files manually with your own text editor. Some of the implications of changing the configuration files in order to customize the user interface are discussed in "Customizing the search interface."
Note
It is not recommended that you make any manual modifications to your
configuration files, but if you do, you must restart the server for your
modifications to take effect.
The configuration files
The configuration files that govern searching are:
webpub.conf
--This system configuration file contains system settings and file paths. In your server's obj.conf
file, the search system initialization is mapped to the webpub.conf
file. When you use the Search Configuration and Search Pattern Files forms, the data you input is reflected in the webpub.conf
file. You can customize your server's search configuration by changing some of the settings in the webpub.conf
file, but in general, you can make the changes you need through the Server Manager's forms. userdefs.ini
--This user definitions file defines the user-defined pattern variables. In the webpub.conf
file, this is mapped to the userdefs.ini
file for your language (English, German, Japanese, and so on).userdefs.ini
file that can be used throughout
your pattern files (See "User-defined pattern variables" for details).
dblist.ini
--This collection contents file describes collection-specific information. In the webpub.conf
file, this is mapped to the dblist.ini
file. When you create and maintain collections, the dblist.ini
file is updated for you with information about your collections.Title
and SourceType
. You can also define META-tagged HTML attributes in your HTML files. Some file formats, such as PDF, have a great many default attributes. See "About collection attributes" and Table 11.2 for more information about the attributes for each format. webpub.conf
file, although larger sets of attributes impact the performance of your server. You cannot set the maximums beyond 100 for text and 50 for dates and numbers.
To do this, you need to manually edit the [NS-loader]
section of the webpub.conf
file to define maximum numbers of attributes. For example, to change all three values, you could use these lines:
NS-max-text-attr = 50
NS-max-numeric-attr = 10
NS-max-date-attr = 10
Note
You cannot use the additional attributes in existing collections, only in subsequently created collections. To use them in a search collection, you must use the Agents & Search|Maintain Collection form to remove the collection and then use the| New Collection form to create a new collection. If you want to use the new attributes in the web publishing collection, you must use your file system to remove both theweb_htm
andlink_mgr
collection files from the search collections directory and then restart your server.
[NS-loader]
section of the webpub.conf
file to add a line defining a maximum memory amount. For example,
NS-max-memory = 32000000The default is for the server to use all of the available memory that the system can offer. Most typically, you need to limit the RAM used for indexing in these two cases:
[NS-loader]
section of the webpub.conf
file to define a maximum index file size. For example,
NS-max-idx-file-size = 1500000Typically, an indexing operation requires approximately 1.5MB per file, and since there are two files, one of which is temporary, you may need as much as 3MB of disk space for indexing. Setting the file size to 1.5MB per file puts a cap on how large each file can become.
When you create a collection, you indicate the type of files that it contains: HTML, ASCII, news, email, PDF, or multiple formats. This determines what happens during indexing: which attributes are indexed and what, if any, file conversion has to be done. Files in multiformat collections are converted to HTML and PDF files are converted to ASCII. You can index all the files in a directory or only those with a specific extension--for example, all the HTML, PDF, or *.doc
documents.
A collection has records with information about each document that has been indexed. If the document is deleted from the collection, only the collection's entry for that document is removed. The original document is not deleted.
About collection attributes
Server documents can be in a variety of formats, such as HTML, Microsoft Excel, Adobe PDF, and WordPerfect. If there is a conversion filter available for a particular file format, the server converts the documents into HTML as it indexes them so that you can use your web browser to view the documents that are found for your search.
There are conversion filters for documents in these formats:
By default, HTML collections have Title
and SourceType
attributes, but they can be indexed to permit searching and sorting by up to 30 file attributes tagged with the HTML <META>
tag. You can change the maximum settings for file attributes in webpub.conf
, as discussed in "Adjusting the maximum number of attributes."
For example, a document could have these lines of HTML code:
<META NAME="Writer" CONTENT="J. S. Smith">
If this document was indexed with its META tags extracted, you could search it for specific values in the writer, publication date, or product fields. For example, you could enter this query:
<META NAME="PubDate" CONTENT="07-24-97">
<META NAME="Product" CONTENT="Communicator">
Writer <contains> Smith
or PubDate > 1/1/97
.
Note
Any attribute values in META-tagged fields are text strings only, which means
that dates and numbers are sorted as text, not as dates or numbers. Also, illegal
HTML characters in a META-tagged attribute are replaced with a hyphen.
Creating a new collection
You can create a collection that indexes the content of all or some of the files in a directory. You can define collections that contain only one kind of file or you can create a collection of documents in various formats that are automatically converted to HTML during indexing. When you define a multiple format collection (with the auto-convert option), the indexer first converts the documents into HTML and then indexes the contents of the HTML documents. The converted HTML documents are put into the html_doc
directory in the server's search collections folder.
Note
You need to have at least 3MB of available disk space on your system to create
a collection. For information on how you can restrict the size of the index files,
see "Restricting your index file size."
To create a new collection, follow these steps:
*.html
pattern in the "Documents matching" field or you can define your own wildcard expression to restrict indexing to documents that match that pattern. For example, you could enter *.html
to only index the content in documents with the .html
extension, or you could use either of these patterns (complete with parentheses) to index all HTML documents:
(*.htm|*.html)
or*(.htm|.html)
You can define multiple wildcards in an expression. See Chapter 3,
"Managing your server" for details of the syntax for wildcard patterns.
Configuring an existing collection
After you have initially created a collection, you can modify some of the initial settings for the collection. This data resides in the collection information file, dblist.ini
, and when you reconfigure a collection, the dblist.ini
file is updated to reflect your changes. See "Configuring manually" for more information about the configuration files. You can revise the description, change its label, define a different URL for its documents, and define how to indicate highlighting in displayed documents, which pattern files to use, and how to format dates.
Note
This form allows you to modify some of the settings for the web publishing
default collection,
To configure a collection, follow these steps:
web_htm,
because you are not changing actual collection
data. Avoid making unnecessary making changes to this collection's settings.
/publisher/help
, and you have changed that mapping to the simpler /helpFiles
, you would replace the URL of /publisher/help
with the /helpFiles
in this field. See "Mapping URLs" for more information about additional document directories.
<b>
and </b>
tags, but you can add to this or change it. For example, you could add <blink><FONT COLOR = #FF0000>
and the corresponding </blink></FONT>
to highlight with blinking bold red text.
/plugins/search/ui/text
folder.
Updating an existing collection
After you have initially created a collection, you may want to add or remove files. If you are adding documents, the files' contents are indexed (and converted if necessary), when their entries are added to the collection. If you are removing documents, the entries for the files are removed from the collection along with their metadata. This function does not affect the original documents, only their entries in the collection.
Note
If you selected the Extract Metatags option when you created this collection,
then the META-tagged HTML attributes are indexed whenever you add new
documents to this collection.
To update a collection, follow these steps:
*.html
, only files with this extension are affected. You can indicate files within a subdirectory by typing in the pathname as it appears in the list of files. For example, you could delete all the HTML files in the /frenchDocs
directory by typing in (no slash before the directory name): frenchDocs/*.html
index.html
, you can add or remove the index file from the
current collection. If instead you type in the expression */index.html
,
you can add or remove all index.html
files in the collection.
/publisher
directory, this option looks for documents matching the new pattern within all the subdirectories within /publisher
. This does not apply for removing documents.
Maintaining an existing collection
Periodically, you may want to maintain your collections. With normal usage, these tasks may not be necessary, but if you do a great deal of indexing and updating of collections, you may want to use some of these functions occasionally. You can perform the following collection management tasks:
*.html
, and add any new documents that fit the original criteria. This option also removes collection entries when the source documents have been deleted and can no longer be found.
Scheduling regular maintenance
You can schedule collection maintenance at regular intervals. You can set up separate maintenance schedules for optimizing and reindexing. With normal usage, these tasks may not be necessary, but if you do a great deal of indexing and updating of collections, you may want to use some of these functions occasionally. For example, some very active web sites may require frequent reindexing if new documents are added on a daily basis.
You can optimize a collection to improve performance if you frequently add, delete, or update documents or directories in your collections. An analogy is defragmenting your hard drive. Optimizing is done automatically when you reindex or update a collection, so you should not need to do additional optimizing. One situation when you might want to optimize a collection is just before publishing it to another site or before putting it onto a read-only CD-ROM.
You can reindex a collection, which locates each file that has an entry in the collection and reindexes its attributes and contents, extracting the META-tagged attributes if that option was selected when the files were originally indexed into the collection. This does not return to the original criteria for creating the collection, say *.html
, and add any new documents that fit the original criteria.
To make your newly scheduled maintenance take effect, you must restart the ns-cron process:
Unscheduling collection maintenance
If you have scheduled regular reindexing or optimizing of a collection, you can remove the scheduled maintenance when you no longer want the collection to be maintained at regular intervals. To do this:
To make your newly scheduled maintenance take effect, you must restart the ns-cron process:
Performing a search: the basics
Users are primarily concerned with asking questions of the data in the search collections and getting a list of documents in return. When you install the Enterprise server, a default set of search query and result forms are included. These allow users a simple method of accessing the search function.
There are four parts to text searching:
http://search-ui/examples
, provides individual links to each of the three search query interfaces as well as an online QuickStart tutorial on customizing the interface. The tutorial discusses the various pattern files and gives examples of how they can be changed to produce different results.
http://
yourServer
/search
Guided search
You can choose to use the Java-based guided search interface, which helps you construct the query. This is especially useful if you want to build a query that has several parts, say searching for a word in the documents' content as well as a specific attribute value.
Note
Make sure Java is enabled for your browser. To do this, use the Languages
option preferences menu command.
There are two ways to obtain the guided search page: through the Search home page or through the standard search query page.
To access guided search through the Search home page, follow these steps:
http://
yourServer/search-ui/examples
To access guided search through the standard search query page, follow these steps:
http://
yourServer
/search
Advanced search
You can choose to use the advanced HTML search interface, which helps you construct the query. This is especially useful if you want to create a query that searches through more than one collection or that produces results sorted by a specific attribute value.
There are two ways to obtain the advanced HTML search page: through the Search home page or through the standard search query page.
To access advanced HTML through the Search home page, follow these steps:
http://
yourServer
/search-ui/examples
To access advanced HTML search through the standard search query page, follow these steps:
http://
yourServer
/search
The search results
There are two standard types of search results: a list of all documents that match the search criteria and the text of a single document that you selected from the list of matching documents.
Listing matched documents
In the default installation of the Netscape Enterprise Server, when you execute a search from either the simple or advanced search query pages, you obtain a list of the documents that match your search criteria. The list gives some standard information about each file, depending on the collection's format. For example, the default results page for email collections give subject, to, from, and date for each entry and news collections give subject, from, and date for each entry.
The kind of file format in the collection indicates which default attributes are available for searching. See "About collection attributes" and Table 11.2 for information about the attributes for each format.
For entries resulting from a search that checks for comparative proximity of words to each other or for the exactness of the match, the file's ranking can be provided by showing a score.
If there are more matching documents than can fit on a page, click Next to see the next batch. You can always execute a new search by entering new query data and clicking Search.
Sorting the results
By default, or if you don't enter anything in the Sort By field on the advanced HTML query page, all documents matching the search are output according to their relevance ranking (for queries that consider this) or their position in the server file database (for other queries).
If you enter an attribute name in the Sort By field, the documents are displayed in an ascending sort sequence. You can list the documents in a descending sort sequence by adding a minus sign (-) prefix to the attribute, as in -keywords
or -title
. You can do a multiple sort, by typing in more than one field, as in Author,-PubDate
.
In a short query, sort order usually isn't critical, but in queries that result in a great many matches, you may want to set a sort value in order to obtain useful search results. Note, however, using a special sort sequence may impact the search's performance.
Note
Attribute values in META-tagged fields are text strings, which means that dates
and numbers are sorted as text, not as dates or numbers. To convert the value
into a date or number, you can create a new property in the Web
Publishing|Add Custom Property form and check the box that marks this
property as a META-tagged attribute.
Displaying a highlighted document
In the default installation of Netscape Enterprise Server, when you obtain a list of the documents that match your search criteria, you can select a single document to view in your web browser. Depending on how the pattern files are set up, the word you entered as your original search query can be highlighted in the displayed document with color, boldface text, or blinking.
To view a highlighted document, you click on a link in the document's entry in the search results. The field you use to access the highlighted document depends on how your search interface has been designed, but in the default installation, you click the document's title. When you click the title's hypertext link, there is additional code defined behind that link to format the displayed document with the search query highlighted. There is another link in the default search result entries that provides the file's URL, but clicking this is the equivalent of opening the file in your browser without any special highlighting.
In the case of documents that have been converted into HTML, the URL points you to the original document. To get to the converted HTML document, click the document's title.
Displaying collection contents
You can display the contents of your collection database to see which attributes are set for each collection. The default installation of Netscape Enterprise Server uses the HTML-description.pat
file to display information about each of your collections that have been defined as displayable (NS-display-select = YES
) in the dblist.ini
file. The collection contents typically include these items:
http://yourServer/search?NS-search-page=c
Note
The query language is not case-sensitive. The examples use uppercase for clarity only.The search engine interprets the search query based on a set of syntax rules. For example, by entering the word region, the actual word region and all its stemmed variations (such as regions and regional) are found. The search results are ranked for "importance," which means how close the matched word comes to the originally input search criteria. In the example above, region would rank higher than any of the stemmed variants. Not all queries rank their results. For example, queries that check whether a given string matches the value in a field cannot perform a comparison: either the string matches the value or it doesn't. The same is true for checking whether a string is contained in a field, or begins or ends a field.
<STEM>
--Search finds all documents that contain any stemmed variant of the search word or phrase. The search engine looks at the meaning of the word, not just its spelling. For example, if you want to search on plan, the results would include documents that contain planning and plans, but not those that contain plane or planet.
<MANY>
--Search considers how often the search word or phrase appear in the found documents and ranks the results for frequency (or relevancy).
<PHRASE>
--Search considers words separated by spaces to be part of a phrase. For example, Monterey otter is interpreted as a phrase and both must be present and together to be found. Such a search would not find documents containing sea otter or Monterey Bay.
Note
In any case where it's not clear that two words are to be considered as a phrase, you can use parentheses for clarity. For example,
<PHRASE> (rise "and" fall).
OR
--Search considers each word or phrase in the query separated by a comma to be optional, although at least one must be present. In effect, this is an implicit OR operation. For example, Monterey, otter is interpreted as find documents that contain either Monterey or otter. Note that angle brackets are not require for OR
.
AND
, OR
, NOT
, and the date and numeric comparison operators, you need to enclose query operators in angle brackets, as in <CONTAINS>
and <WILDCARD>
.
Monterey AND Bay NOT <CONTAINS> AquariumYou can achieve even greater precision by including some implicit phrases, as in the following query that finds documents that refer to the Monterey Bay Aquarium by its full name and also mention otters but do not refer to shark:
Monterey Bay Aquarium AND otter AND NOT shark
<CONTAINS> ebb "and" flow
"plan"This search only results in documents that contain the exact word plan. It ignores documents with plans or planning.
Title NOT <CONTAINS> theme park
Query operators: a reference
The following table describes some commonly used operators and provides examples of how to use each one. All are relevance ranked except where explicitly noted.
Using wildcards
You can use wildcards to obtain special results. For example, you can find documents that contain words that have similar spellings but are not stemmed variants. For example, plan stems into plans and planning but not plane or planet. With wildcards, you can find all of these words.
Some characters, such as * and ?, automatically indicate a wildcard-based search and do not require you to use the <WILDCARD>
operator as part of the expression.
Non-alphanumeric characters
You can only search for non-alphanumeric characters if the style.lex
file used to create the collection is set up to recognize them. This file is in the HTML, news, and mail subdirectories in the server_root/plugins/common/
directory.
Wildcards as literals
Sometimes you may want to search on characters that are normally used as wildcards, such as *or ?. To use a wildcard as a literal, you must precede it with a backslash. In the case of asterisks, you must use two backslashes. For example, to search on a magazine with a title of Zine***, you would type:
<WILDCARD>Zine\\*\\*\\*
Several characters have special meaning for the search engine and require you to use back quotes to be interpreted as literals. The special search characters are listed here:
style.lex
file has been set up to recognize it.)<WILDCARD>`a{b`For another example, if you wanted to search on the string "c`t", which contains a back quote, you would type
<WILDCARD>`c``t`
userdefs.ini
, webpub.conf
, and dblist.ini
, which are discussed in "Configuring manually.")
Note
The search home page, at
http://
yourServer/search-ui/examples
,
also provides an introduction to the search interface as well as an online
QuickStart tutorial on customizing the interface. The tutorial discusses the
various pattern files and gives examples of how they can be changed to
produce different results.
HTML pattern files
A good place to begin customizing the interface is by modifying the existing pattern files. After you see how they work and you understand pattern variables, you can create your own pattern files and change the configuration files and other pattern files to point to them. In the default installation of Netscape Enterprise Server, the pattern files are in this directory: server_root/plugins/search/ui/text
. (Make copies of your original pattern files so you can restore them afterwards.)
There are pattern files for different kinds of collections: email, news, ASCII, PDF, and HTML as well as one for the web publishing collection. (The web publishing pattern file is a special case, using a great many collection-specific attributes as variables in the dblist.ini
file.) There are several general types of pattern files, each of which has a particular use:
query.pat
displays the standard and advanced query pagestocstart.pat
displays the header across the top of the search results pagetocrec.pat
displays each document listed on the search results pagetocend.pat
displays the footer across the bottom of the search results pagerecord.pat
displays a single highlighted document from the search results page (See "Displaying a highlighted document" for more information.)descriptions.pat
displays the collection contents
userdefs.ini
file, with a $$
prefix (See "User-defined pattern variables").webpub.conf
and dblist.ini
files, with a $$NS-
prefix (See "Configuration file variables," Table 11.8, and Table 11.9).$$NS-
prefix (See "Macros and generated pattern variables" and Table 11.10).NS-query.pat
:
<input type="hidden" name="NS-max-records" value="$$NS-max-records">Each line contains standard HTML tags and one or more variables with the
<td align=left colspan=2>$$logo</td>
<td align=right><h3>$$sitename</h3></td>
<td align=right><b>$$queryLabel</b></td>
<td align=left> <input name="NS-query" size=40 value="$$NS-display-query"></td>
$$
or $$NS-
prefix. Examining each line more closely requires looking at the configuration files mentioned in "Configuring manually."
NS-max-records
: Defined in the webpub.conf
file. Because this field is hidden, users cannot change this value, which defines how many matching documents to return at a time. In the advanced HTML query pattern file, NS-advquery.pat
, this is a user-modifiable input field.$$NS-max-records
: The search generates a variable from this field that can be used in subsequent searches to calculate how many result records to display at a time. Because this field is not modifiable here, the value is set to that in webpub.conf
file. In the advanced query, this value could vary for each query. $$logo
: Defined in the userdefs.ini
file. This could be any image or text the user wanted to display on the form. $$sitename
: Defined in the userdefs.ini
file as the server's host name that is provided by the $$NS-host
search macro. $$queryLabel
: Defined in the userdefs.ini
file as a text label for the query input field. In this case, the label on the form is the word "For:"NS-query
: Defined in this pattern file as the name of the input field. $$NS-display-query
: Defined in the userdefs.ini
file. The search generates a variable from this field that can be used in subsequent searches to determine which word or phrase to highlight when an entire matching document is displayed. http://yourServer/search?name=value[&name=value][&name=value]As you use the HTML search query and results pages, you can see search functions and arguments displayed in the URL field of your browser. When entered directly into the URL field, these are sometimes called decorated URLs. You can also embed them in your pattern files with the HREF tag. You can create a complete search function as an HREF element within a pattern file. The example given is from the HTML-descriptions.pat file, which defined how collection information is displayed. The following lines produce a heading for each collection for the label ("Collection:") and provides a link to the actual collection file through the collection's label (
NS-collection-alias
) that was defined in the dblist.ini
file.
<td colspan=6><font size=+2><b>$$collectionLabel</b>The HREF contains a complete search function by using the following elements:
<a href=$$NS-server-url/search?NS-collection=$$NS-collection>$$NS-collection-alias</a>
</font></td>
$$NS-server-url
: A search macro that determines the user's server URL./search
: The search command itself.?
: The query string indicator. Everything after the ? is information used by the search function.NS-collection=$$NS-collection
: This uses the search macro $$NS-collection
to define the collection's filename. variableName[conditionalized output]For example, you could request that the document's title be output if it exists. If there is no title for this document, not even the label "Title:" is to be displayed. To do this, you would use code like this:
$$Title[<P>Title: <B>$$Title</B>]
Character | Description | Code |
---|---|---|
Space | %20 | |
; | Semicolon | %3B |
/ | Slash | %2F |
? | Question mark | %3F |
: | Colon | %3A |
@ | At sign | %40 |
= | Equal sign | %3D |
& | Ampersand | %26 |
Required search arguments
Although you can customize almost every aspect of query and result pages, there are some arguments required for search functions to display the different types of search pages. These arguments are required whether the search function is in a decorated URL or embedded as an HREF in a pattern file.
Search functions that display the search query page require these arguments:
NS-search-page=results
(or r
, in upper- or lowercase)NS-search-page
=document
(or d
, in upper- or lowercase)NS-search-page=contents
(or c
, in upper- or lowercase)userdefs.ini
file, to which are added a $$
prefix in decorated URLs and pattern files. For example, uidir
, logo
, and title
become $$uidir
, $$logo
, and $$title
.webpub.conf
and dblist.ini
files, which have a NS-
prefix where they are defined in the configuration file and which have a $$NS-
prefix when they are used in decorated URLs and pattern files. For example, NS-max-records
, NS-doc-root
, and NS-date-time
become $$NS-max-records
, $$NS-doc-root
, and $$NS-date-time
.$$NS-
prefix. For example, $$NS-host
, $$NS-get-next
, and $$NS-sort-by
.userdefs.ini
, or you can modify existing definitions. When one of these variables is used in a pattern file, the $$ prefix is added to it. Variable names can have up to 32 characters or digits, or combinations of both. Characters can be letters A-Z in upper or lower case, hyphens (-), and underscores (_). Names are case sensitive.
The default userdefs.ini
file included with Netscape Enterprise Server contains variables that are used to define the search query page (labeled [query
] in the file, the results listing ( labeled [toc]
), the document display page, (labeled [record]
), and the collection contents page (labeled [contents]
). Each line begins with a variable name and is followed by a definition for that variable. Many are labels for screen elements, some are paths to other files, and some have more complex contents. For example, the following lines are from the query section of that file.
[query]The file also includes references to search macros, such as $$NS-server-url, and can also refer to other user-defined variables, as in the following lines:
help=/publisher/help/srchhelp.html
title=ES3.0 Sample Search Interface
queryLabel=Search for:
collectionLabel=Collection:
booleanLabel=Boolean:
sortByLabel= Sort for:
copyright = Copyright © 1997 Netscape Communications Corporation. All Rights Reserved.
uidir = $$NS-server-url/search-uiSearch macros are described further in the section "Macros and generated pattern variables."
icondir = $$uidir/icons
You can use any supported HTML character entity in your variable definitions. You can use entity names that are defined in the &name; format as well as those defined with the three-digit code in the &#nnn; format. In the userdefs.ini
code sample, the entity
inserts a nonbreaking space and ©
inserts a copyright symbol. Some of the more commonly used entities are in Table 11.7.
Configuration file variables
Some variables are defined in the system configuration and the collection configuration files. These use a prefix of NS-
in the configuration file to differentiate them from other markup tags in an HTML page. To use these variables as arguments to the search function, you add another prefix $$
to the variable, as in $$NS-date-time
and $$NS-max-records
.
Variables that define defaults for all searches on a server are defined in the system configuration file,
webpub.conf
. For example, the default installation of Netscape Enterprise Server includes the following variables in the webpub.conf
file:
NS-max-records = 20
Although installations may vary depending on how each server is configured, the most commonly found variables from the
NS-query-pat = /text/NS-query.pat
NS-ms-tocstart = /text/HTML-tocstart.pat
NS-ms-tocend = /text/HTML-tocend.pat
NS-default-html-title = (Untitled)
NS-HTML-descriptions-pat = /text/HTML-descriptions.pat
NS-date-time = %b-%d-%y %H:%M
webpub.conf
file are listed in Table 11.8.
Collection-specific variables are defined in the dblist.ini
file. For example, the default installation of Netscape Enterprise Server includes variables for the web publishing collection. Among the variables defined there are:
NS-collection-alias = Web Publishing
The variables in your
NS-doc-root = C:/Netscape/SuiteSpot/docs
NS-url-base = /
NS-display-select = YES
dblist.ini
file may differ according to the type of collections you are using, Table 11.9 contains some of the more commonly found collection-specific variables.
Macros and generated pattern variables
There are some search macros that you can use in your pattern files or decorated URLs, and the search function itself generates some pattern variables that you can use in subsequent search requests to define how the later output is to be displayed. These macros and variables have a prefix of $$NS-
to indicate their use.
For example, after doing an initial search query that results in 24 documents on the results page, you can reuse the search-generated $$NS-docs-matched
and the $$NS-doc-number
variables to help define a document page displaying one of the documents in detail. In this way, you can tell the user that this document is number 3 of 24 documents returned for the original search.
The search macros and the generated variables that you can use in a subsequent pattern file or decorated URL are listed in Table 11.10.