<The previous article in this series | The table of contents of this series | The next article in this series>
To Know How to Handle (Read or Write) LibreOffice or Apache OpenOffice Writer or Calc Documents via Extensions from Java or Macro Programs
A Sample UNO Extension Project
The 'hiUnoExtensionsUnoExtension' directory contains a sample UNO extension project.
Explanations of the 'build.xml' and 'build.gradle' files, the directories, 'source', 'java', and 'resource', and 'MANIFEST.MF.addition' are the same as before. . . .
. . . And?
The rest is the difficult part to explain. 'HiUnoExtensionsImplementation.java' is a UNO interface implementation class.
. . .
. . . Just accept for now that there is a concept called UNO interface, which is mapped to Java interface. 'HiUnoExtensionsImplementation.java' is an implementation of a Java interface mapped from a UNO interface.
OK.
'HiUnoExtensionsUnoExtensionGlobalServicesProvider.java' is a class that is necessary for the UNO interface implementation to be registered as a global UNO service into LibreOffice. Such a class is called a 'global UNO services' provider.
. . .
. . . Just, please, accept for now that there is a concept called global UNO service. Not all UNO interface implementations have to be registered as global UNO services, but when we want some UNO interface implementations to be registered as global UNO services, we need to have a 'global UNO services' provider.
One 'global UNO services' provider for multiple global UNO services?
Yes. A UNO extension can contain multiple UNO interface implementations, and some of them can be registered as global UNO services, but there is only one 'global UNO services' provider in the UNO extension.
What do we have to describe in the 'global UNO services' provider?
We have to associate a UNO service name to each UNO interface implementation to be registered as a global UNO service. 'GlobalUnoServicesProviderUtility.java' in the 'unoUtilitiesToDisclose' project contains static methods used by 'global UNO services' providers. That is, common codes used by all the 'global UNO services' providers have been separated from the 'global UNO services' providers into the class.
I see.
The 'manifest.xml' file in the 'resource' directory is the manifest file of the UNO extension file.
The UNO extension file?
The UNO extension is archived as a zip file, which is the UNO extension file.
What do we have to describe in the manifest file?
We have to describe what UNO data types registry file is included in the UNO extension, and we have to also name a UNO components setting file, which I will explain next.
What is a UNO data types registry file?
As UNO is 'programming language'-independent, UNO data types like UNO interfaces have to be registered into LibreOffice in a 'programming language'-independent form. The UNO data types registry file contains definitions of UNO data types in that 'programming language'-independent form.
How is the UNO data types registry file created?
We can create it from UNO-specific source files using UNO tools.
Hmm . . .
The 'thebiasplanet.hiunoextensionsunoextension.uno.components' file is the UNO components setting file named in the manifest file. The UNO components setting file specifies what UNO interface implementations are included in the UNO extension. And in the setting file, we also associate UNO service names to UNO interface implementations that are registered as global UNO services.
. . . Haven't we already designated that information in the 'global UNO services' provider?
Well, . . . if you accuse of its being redundant, I think, it's redundant.
Hmm, if it's required, it can't be helped.
The 'unoIdl' directory is the root directory of UNOIDL (UNO Interface Definition Language) files.
. . .
. . . UNOIDL is a definition language in which UNO artifacts are defined. For example, the UNO interface is first defined in UNOIDL in a UNOIDL file; the UNO interface is converted to a Java interface class file and a UNO data type unmerged registry file by UNO tools. Actually, UNOIDL files are what I meant by 'UNO-specific source files'.
A UNO data type unmerged registry file?
First, we create a UNO data type unmerged registry file per UNO data type. Next, we merge those UNO data type unmerged registry files into a UNO data types merged registry file, which is the aforementioned UNO data types registry file.
Ah-ha.
The directories, like 'thebiasplanet', under the 'unoIdl' directory represent UNO modules. We can think of the UNO module as an equivalent of a Java package. In fact, the UNO module is mapped to a Java package.
'XHiUnoExtensions.idl' is a UNOIDL file in which a UNO interface is defined.
About 'HiUnoExtensions.idl' . . .
. . . About that, what?
As descriptions in the reference documents are confusing, I will describe it in my terms. 'HiUnoExtensions.idl' is a UNOIDL file in which a 'global UNO service' instances factory is defined.
I understand your description, but what are descriptions in the reference documents?
They are as though a 'UNO new-style service' is defined in it.
What are UNO new-style services?
The usage of terms, 'UNO new-style service' and 'UNO old-style service' in the reference documents is confusing, and I can't explain it here (we will delve into it when we learn basic concepts of UNO). But anyway, 'UNO new-style service' sounds like a kind of UNO service, but what is defined in that UNOIDL file isn't a UNO service itself, but a UNO service instances factory.
What exactly is described in the UNOIDL file?
So-called 'constructors' are described in the UNOIDL file; the UNOIDL file is converted to a Java class that has those 'constructors' as static methods. We can create 'global UNO service' instances by calling those static methods.
So, 'constructors' aren't constructors in the Java terminology, but factory methods. The Java class converted from the UNOIDL file is a UNO service instances factory, not a UNO service.
That's what I mean. In fact, we don't have to create the UNOIDL file for us to register and use the global UNO service, if we don't intend to use that type of UNO service instances factory.
But don't we need a kind of UNO service instances factory to instantiate the global UNO service?
Yes, but there is a generic UNO service instances factory called global UNO services manager, and we can instantiate the global UNO service from the global UNO services manager. By 'generic', I mean, the global UNO services manager can instantiate multiple UNO services while the UNO service instances factory converted from the UNOIDL file is a 'UNO service'-specific UNO service instances factory that can instantiate only the specific UNO service.
I understand.
- Apache OpenOffice Wiki. (2014/01/02). Apache OpenOffice Developer's Guide. Retrieved from https://wiki.openoffice.org/wiki/Documentation/DevGuide/OpenOffice.org_Developers_Guide
<The previous article in this series | The table of contents of this series | The next article in this series>
