5.2 Using Components

Components are modular programs that are designed to interact with the Content Server at run time. The component architecture model is derived from object-oriented technologies, and encourages the use of small modules to customize the Content Server as necessary, rather than creation of a huge, all-inclusive (but cumbersome) application.

Any type of file can be included in a component, but the following file formats are used most often:

• HDA

• HTM

• CFG

• Java CLASS

Components are typically used to alter the core functionality of the Content Server. For example, a component could be used to:

• Modify the standard security features

• Change the way search results are requested and returned

• Allow the Content Server to work with a particular system (such as a Macintosh client or a proprietary CAD program)

The advantages of using component architecture with the Content Server include the following:

• You can modify source code without compromising the integrity of the product. The Content Server loads many of its resources from external text files, so you can view the files to analyze how the system works, and then copy and modify the files to your requirements.

• You can use a custom component on multiple instances across multiple platforms. When you have created a custom component, you can package it as a zip file and load it on other Content Server instances. Many custom components can work on Content Server platforms other than the original development platform.

• You can turn individual components on and off for troubleshooting purposes. You can group customizations so that each component customizes a specific Content Server function or area. If you have problems, disabling components one at a time can help you quickly isolate the trouble.

• You can reinstall or upgrade a Content Server without compromising customizations. Custom components override existing product resources rather than replace them. Replacing the standard Content Server files might not affect your customizations.

Keep the following constraints in mind when deciding whether to use custom components:

• Custom components change behavior and look-and-feel systemwide. If you want your changes to apply only in limited situations, you might want to consider dynamic server pages.

• Custom components can be affected by changes to Content Server core functionality. Because new functionality may change the way your components behave, customizations are not guaranteed to work for future Content Server releases. Whenever you upgrade, you should review and test your custom components.

• A component may not be necessary for simple customizations. A large number of simple components could become difficult to manage.

Components must be installed and enabled to be used by Content Server. Components provided with Content Server are automatically installed, and they are enabled or disabled by default. Custom components must be installed and enabled to be usable. Several tools are available for working with components:

• The Component Wizard automates the process of creating custom components. You can use the Component Wizard to create new components, modify existing components, and package components for use on other Content Server instances. For details see "Component Wizard".

• The Advanced Component Manager provides a way to manage custom components in the Content Server. By using the Advanced Component Manager, you can add new components and enable or disable components on the Content Server. For details see "Advanced Component Manager".

• The ComponentTool is a command-line utility for installing, enabling, and disabling components in Content Server.

For information on component architecture and creation, see Chapter 3, "Working with Components."