Deciding Which Interface to Expose
Before a component can be configured through a macro language such as Microsoft Visual Basic Scripting Edition (VBScript), it must implement the IDispatch interface. Because any interface that you create can inherit from the IDispatch interface, you decide which of the interfaces that you implement will use the IDispatch interface to expose the properties and methods of your component.
Several options are available. When you add an object to your project, Microsoft Visual C++ adds an interface to the object definition that appears in the interface definition language (IDL) file for the project. By default, the interface that Visual C++ adds inherits from the IDispatch interface.
You can use this interface, or you can implement the IPipelineComponentAdmin interface. This interface is defined by Commerce Server 2000 specifically to enable component writers to expose their component properties. The IPipelineComponentAdmin interface defines two methods: GetConfigData and SetConfigData. These methods take a Dictionary object as a parameter, and read or write to this Dictionary object to retrieve or set the values of the properties of the component.
The options described in the preceding paragraphs are mutually exclusive; you cannot implement two IDispatch interfaces on a single object and make both available to Active Server Pages (ASP) clients.
The following lists the advantages of using the Visual C++ user interface to get an IDispatch implementation:
Implementing IDispatch::Invoke is done automatically. By adding properties and methods through the Visual C++ user interface, this work is done for you.
As you add properties and methods to your object, Visual C++ automatically adds the appropriate entries to the project IDL, header, and implementation files. Because the added interface is the default interface for the object, a VBScript client that creates an instance of your object using the ProgID gets this interface, and can set the methods and invoke the properties implemented in it.
According to the rules for Component Object Models (COM), the advantage of implementing the IPipelineComponentAdmin interface is that after an interface is published, it cannot be changed. By adding properties to a published object, you necessarily modify the dispatched interface, running the risk that you will break the client code of existing users. Because implementing the IPipelineComponentAdmin interface does not require that your component definition be modified to add support for new properties, your component can evolve over time without requiring the publication of a new interface. The IPipelineComponentAdmin interface also allows for simple persistence, because the dictionary supports persistence. And the dictionary exposed through the IPipelineComponentAdmin interface supports enumeration of property names.
The IPipelineComponentAdmin interface is required if you are implementing a shipping component that requires configuration.
.gif "Ee783789.important(en-US,CS.10).gif")
Important
- Shipping Components should expose the IPipelineComponentAdmin::GetConfigData and IPipelineComponentAdmin::SetConfigData methods from the IDispatch interface implementation, because the Commerce Server Business Desk module(s) that manage these components must be able to call these methods from a late-bound (Active Server Pages) environment.
See Also
Implementing the IPipelineComponent Interface