The Component Description File

Each component must be named in the component directory’s description file, and associated with another file: the component implementation file. The binding between a given component and this file is established by the component description file. A single component template file can describe multiple custom components, and a single object library, executable program, or script file can contain the implementation for multiple custom components.

A component description file uses the Windows INI file format. The following is a sample component description file specifying two components that use the same implementation and template files:

[info]
list=ComponentOne,ComponentTwo
clientarchitectures=All
serverarchitectures=All
vendor=Microsoft
contact=http://www.microsoft.com
version=0.1
serverbinding=stdio
servermodule=newbots.pl
clientbinding=BTL
clientmodule=newcomponents.htm

[ComponentOne]
name=New Component One
description=something or other
type=insert

[ComponentTwo]
name=New Component Two
description=something or other
type=insert

The component description file must contain an [info] section; its keys apply to all of the components in the directory. If the directory contains only one component, then all of the keys can go into the [info] section. If there are multiple components in the directory, each one must have a separate section with the same name as the component.

Per-Directory Keys

The keys stored in the component description file’s [info] section are:

list
A comma-separated list of component shortnames enumerating the components in this directory. The shortnames must be unique across all components in the web. An easy way to do this is to pre-pend a company name to the name of the component. This is an optional parameter; if not present, there is only one component in this description file (whose shortname is the basename of the info file) and all keys are in the [info] section.

serverarchitectures
Reserved for future use. This is an optional parameter. If present, the value should be “All”.

clientarchitectures
Must be present for the client to be able to insert a new FrontPage component of this type into a page. For this release, the value should be either “All” or “WinI386”. If you set the clientBinding key (see below) to type “DLL”, you should use “WinI386” so that only Windows clients will download the module. For a clientBinding of type “BTL”, you should use “All” so that any client can use it. You should always provide a BTL binding in addition to any DLL binding, so that all FrontPage clients can use the component. This key is mandatory for the client and optional for the server.

version
A version number, which can be an integer or decimal number. This is a mandatory parameter. The FrontPage client compares the FrontPage component’s version number in the \botcache directory with the version number reported by the FrontPage server during a recalculate links or open web operation. The client will not download a fresh DLL from the server unless the version number on the server is greater than the version number cached on the client. To make sure all clients will recognize a new version of a FrontPage component DLL, you should increment the FrontPage component’s version number (even if it’s by .01) and do a Recalculate Hyperlinks operation in the FrontPage Explorer.

vendor
The component vendor’s name. This is an optional parameter.

contact
How to contact the vendor (by URL, telephone, etc.). This is an optional parameter.

serverBinding
The method for interfacing with the server-side implementation. Possible values are “DLL” or “Stdio”. Windows servers This is a mandatory parameter if this directory includes a component implementation file.

serverModule
References the server-side implementation file (library, executable file, or script). This is a mandatory parameter if this directory includes a server-side implementation.

serverInterpreter
If the serverModule is a script (which implies that serverBinding must be Stdio) and the server OS cannot auto-execute scripts (such as Windows) then this key identifies the script interpreter. If this directive is present then instead of executing serverModule, FrontPage will execute serverInterpreter and pass it serverModule as its first argument.

clientBinding
The method for interfacing with the client-side implementation. There are two possible values: “DLL” or “BTL” (Bot Template Language – described below). This is a mandatory parameter if this directory includes a client-side implementation.

clientModule
References the client-side implementation file. This is a mandatory parameter if this directory includes a client-side implementation. This points to the file containing the template or the DLL. For convenience, template files usually have a .htm extension.

Per-Bot Keys

If more than one custom FrontPage component is specified in the description file, then each component mentioned in the [info] section’s “list” key should have its own section with the same name (which is called the component’s shortname) and the following keys. If only one component is specified in the component directory, then these per- component keys can be placed in the [info] section.

The keys stored in the per- component sections are:

name
The displayable name of the component (also called the component’s longname), as shown in the FrontPage Editor’s Insert : FrontPage Component dialog. This is an optional parameter. It defaults to the component’s shortname.

description
A short description of the component. This is an optional parameter.

type
The type of component. Possible values are “insert” or “form”. A form component handles form submissions, while an insert component usually replaces itself with some HTML. This is a mandatory parameter.

Supporting Multiple Client Bindings

A component can provide more than one client binding. In fact, any component that provides a DLL interface should provide at least two: a DLL binding for the WinI386 client architecture, and BTL client binding for all other client architectures. The following example shows how to specify both platform-dependent and platform-independent client bindings in a component’s INF file, with a preference for the platform-dependent version:

[info]

list=HitCounter
clientarchitectures=WinI386,all
vendor=Microsoft
contact=http://www.microsoft.com
version=2.1
serverbinding=dll
servermodule=fpcntsrv.dll
clientbinding=BTL
clientmodule=fpcntclt.btl

[WinI386]

clientbinding=dll
clientmodule=fpcntclt.dll

[HitCounter]

name=Hit Counter
description=Adds a hit counter to your page
type=insert