Configuration

OpenOffice.org Developer's Guide

Writing UNO Components

< Previous Section

Next Section >

• Required Files
• Using UNOIDL to Specify New Components

• Writing the Specification

• Preprocessing
• Grouping Definitions in Modules
• Simple Types
• Defining an Interface
• Defining a Service
• Defining a Sequence
• Defining a Struct
• Defining an Exception
• Predefining Values
• Using Comments
• Singleton
• Reserved Types
• Published Entities

• Generating Source Code from UNOIDL Definitions

• Component Architecture
• Core Interfaces to Implement

• XInterface
• XTypeProvider
• XServiceInfo
• XWeak
• XComponent
• XInitialization
• XMain
• XAggregation
• XUnoTunnel

• Simple Component in Java

• Class Definition with Helper Class
• Implementing Your Own Interfaces
• Providing a Single Factory Using a Helper Method
• Write Registration Info Using a Helper Method
• Implementing without Helpers
• Storing the Service Manager for Further Use
• Create Instance with Arguments
• Possible Structures for Java Components
• Running and Debugging Java Components

• Register Component File
• Make Registration Available to OpenOffice.org
• Test the Registration
• Debugging
• The Java Environment in OpenOffice.org
• Troubleshooting

• C++ Component

• Class Definition with Helper Template Classes
• Implementing your own Interfaces
• Providing a Single Factory Using a Helper Method
• Write Registration Info Using a Helper Method
• Provide Implementation Environment
• Implementing without Helpers
• Storing the Service Manager for Further Use
• Create Instance with Arguments
• Multiple Components in One Dynamic Link Library
• Building and Testing C++ Components

• Integrating Components into OpenOffice.org

• Protocol Handler

• Implementation
• Configuration
• Installation

• Jobs

• Execution Environment
• Implementation
• Initialization
• Returning Results
• Configuration
• Installation
• Using the vnd.sun.star.jobs: URL Schema
• List of Supported Events

• Add-Ons

• Guidelines
• Configuration

• Menus
• Toolbars
• Images for Toolbars and Menus
• Help Integration

• Installation

• Disable Commands
• Intercepting Context Menus

• File Naming Conventions
• Deployment Options for Components

• Command Line Registry Tools
• Manual Component Installation
• Bootstrapping a Service Manager
• Special Service Manager Configurations

• The UNO Executable

• Standalone Use Case
• Server Use Case
• Using the UNO Executable

• Accessing Dialogs

• Assigning Component Methods to Control Events
• Using Dialogs in Components

< Previous Page

Next Page >

A protocol handler needs configuration entries, which provide the framework with the necessary information to find the handler. The schema of the configuration branch org.openoffice.Office.ProtocolHandler defines how to bind handler instances to their URL schemas:

  <?xml version="1.0" encoding="UTF-8"?>
  <!DOCTYPE oor:component-schema SYSTEM "../../../../component-schema.dtd">
  <oor:component-schema xmlns:oor="http://openoffice.org/2001/registry" 
                        xmlns:xs="http://www.w3.org/2001/XMLSchema" 
                        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
                        oor:name="ProtocolHandler" 
                        oor:package="org.openoffice.Office" 
                        xml:lang="en-US">
      <templates>
          <group oor:name="Handler">
              <prop oor:name="Protocols" oor:type="oor:string-list"/>
          </group>
      </templates>
          <component>
              <set oor:name="HandlerSet" oor:node-type="Handler"/>
          </component>
  </oor:component-schema>

Each set node entry specifies one protocol handler, using its UNO implementation name. The only property it has is the Protocols item. Its type must be [string-list] and it contains a list of URL schemas bound to the handler. Wildcards are allowed, otherwise the entire string must match the dispatched URL.

Configuration for vnd.sun.star.framework.ExampleHandler

The following example ProtocolHandler.xcu contains the protocol handler configuration for the example's Java protocol handler:

  <?xml version='1.0' encoding='UTF-8'?>
  <oor:component-data oor:name="ProtocolHandler" 
                      oor:package="org.openoffice.Office" 
                      xmlns:oor="http://openoffice.org/2001/registry" 
                      xmlns:xs="http://www.w3.org/2001/XMLSchema" 
                      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
      <node oor:name="HandlerSet">
          <node oor:name="vnd.sun.star.framework.ExampleHandler" oor:op="replace">
              <prop oor:name="Protocols">
                  <value>myProtocol_1://* myProtocol_2://*</value>
              </prop>
          </node>
      </node>
  </oor:component-data>

The example adds two new URL protocols using wildcards:

 myProtocol_1://*
myProtocol_2://*

Both protocols are bound to the handler implementation vnd.sun.star.framework.ExampleHandler. Note that this must be the implementation name of the handler, not the name of the service com.sun.star.frame.ProtocolHandler it implements. Because all implementations of the service com.sun.star.frame.ProtocolHandler share the same UNO service name, you cannot use this name in the configuration files.

To prevent ambiguous implementation names, the following naming schema for implementation names is frequently used:

 vnd.<namespace_of_company>.<namespace_of_implementation>.<class_name> 

e.g. vnd.sun.star.framework.ExampleHandler

<namespace_of_company>= sun.star
<namespace_of_implementation>= framework
<class_name>= ExampleHandler 

An alternative would be the naming convention proposed in XServiceInfo:

 <namespace_of_creator>.comp.<namespace_of_implementation>.<class_name> 

e.g. org.openoffice.comp.framework.OProtocolHandler

All of these conventions are proposals; what matters is:

• use the implementation name in the configuration file, not the general service name "com.sun.star.frame.ProtocolHandler"
• be careful to choose an implementation name that is likely to be unique, and be aware that your handler ceases to function when another developer adds a handler with the same name.

Configuration for org.openoffice.Office.addon.example

The following ProtocolHandler.xcu file configures the example's C++ protocol handler with the implementation name org.openoffice.Office.addon.example in the configuration branch org.openoffice.Office.ProtocolHandler following the same schema.

  <?xml version="1.0" encoding="UTF-8"?>
  <oor:component-data xmlns:oor="http://openoffice.org/2001/registry" xmlns:xs="http://www.w3.org/2001/XMLSchema" oor:name="ProtocolHandler" oor:package="org.openoffice.Office"> 
      <node oor:name="HandlerSet"> 
          <node oor:name="org.openoffice.Office.addon.example" oor:op="replace"> 
              <prop oor:name="Protocols" oor:type="oor:string-list">
                  <value>org.openoffice.Office.addon.example:*</value> 
              </prop> 
          </node> 
      </node>
  </oor:component-data>

The configuration adds one new URL protocol using wildcards:

 org.openoffice.Office.addon.example:*

Based on this URL protocol, the C++ protocol handler can route, for example, a dispatched URL

 org.openoffice.Office.addon.example:Function1 

to the corresponding target routine. See the implementation of the dispatch() method in the XDispatch interface of the C++ source fragment above.

Content on this page is licensed under the Public Documentation License (PDL).