<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
What Are UNO Proxies?
As we have already learned, the UNO object can be handled from another programming language environment. However, how can we do that? We can't just handle the UNO object that lives in a different programming language environment. . . . So, we get a proxy to the remote UNO object.
Let's clarify things more. There is a programming language environment, PLE-A, and a UNO object, UO-A-A, lives in PLE-A; there is another programming language environment, PLE-B, and we want to handle UO-A-A from PLE-B.
Yes. In that case, we get a UNO proxy, UP-B-A, in PLE-B; we handle UP-B-A in PLE-B; and UP-B-A handles UO-A-A.
How do we get the UNO proxy?
Well, suppose that a UNO object, UO-A-A0, already exists in PLE-A, and we already have a UNO proxy, UP-B-A0 in PLE-B. . . . Don't ask how we got UP-B-A0, for now: I will explain it later.
. . . OK.
Suppose that a method of UO-A-A0 creates and return the UNO object, UO-A-A.
All right.
When we call the corresponding method of UP-B-A0 in PLE-B, the bridge transmits the call, the method of UO-A-A0 is called in PLE-A, UO-A-A is created in PLE-A, the bridge transmits the return operation, and UP-B-A is created and returned to us in PLE-B.
So, the bridge creates the proxy, UP-B-A, in PLE-B, and returns us the reference to UP-B-A.
I don't know for sure whether we should say that the bridge creates the proxy, UP-B-A, or we should say that the proxy, UP-B-A0, creates the proxy, UP-B-A, but anyway, we get the proxy, UP-B-A, through the cooperative work of the bridge and the proxy, UP-B-A0.
I see. . . . So now, can I ask how do we get UP-B-A0?
When we establishes the UNO bridge from PLE-B to PLE-A, we receive a thing called a UNO component context. The UNO component context contains a UNO proxy to a thing called, 'the global UNO service manager' in PLE-A, as a property.
So, the UNO proxy to the global UNO service manager acts as the first UNO proxy, beginning from which we can get other UNO proxies one by one.
Yes.
What Are UNO Component Contexts?
The term, 'UNO component context', appeared in the last section; what are UNO component contexts, exactly?
Conceptually, the UNO component context is a handle to a programming language environment (we will call a programming language environment that supports UNO a 'UNO environment'): once we get a UNO component context of a UNO environment, we can do whatever allowed us to do to the UNO environment.
From the perspective of implementation, the UNO component context is a container of some properties as the run time environment. In fact, the global UNO service manager is one of those properties.
As we learned from the last section, we can access UNO objects of a UNO environment starting from the UNO component context via the global UNO service manager, which is what 'the UNO component context is a handle to a UNO environment' means.
How Can We Create UNO Objects? What Are UNO Services? What Are UNO Services Managers?
As you may expect, I have to ask what the global UNO service manager is.
Well, that concerns how we create UNO objects. . . . We create a UNO object from a UNO component, and the basic way to create a class instance from a class in Java is to call the 'new' operator.
Yes.
However, when we call the 'new' operator, we hard-code the name of the class from which the class instance is created. . . . To avoid the hard-coding, sometimes, a concept called factory is used. The global UNO services manager is a factory of UNO objects.
So, we ask the global UNO services manager to give us a kind of UNO object without specifying the exact implementation class; the global UNO services manager determines which implementation class to use, create a UNO object from the implementation class, and return the UNO object to us.
Yes.
You used the term, 'UNO service', unexplained.
Yes. . . . You said, "a kind of UNO object", and that kind is a UNO service. . . . We want a UNO object, but it isn't that any UNO object will do: we need a specific kind of UNO object.
Ah-ha, specifying the exact implementation class is a way to specify the kind, but that is a hard-coding. So, we define a name, associate the exact implementation class with the name, and UNO objects users specify the name, not the implementation class. . . . Eventually, we can associate another implementation class with the name without requiring UNO objects users to change their codes.
Yes. That name is a service name. And note that in some cases, multiple implementation classes are associated with the same service name at the same time, and the implementation class to be used is determined based on the context of the request for a UNO object.
I wonder what the adjective, 'global' means. Are there also not-global UNO services managers?
Yes, there are UNO services managers other than the global UNO services manager. Each of those UNO services managers creates instances of specific UNO services, not all the UNO services.
So, a UNO services manager can create instances of UNO services, US-A and US-B, and another UNO services manager can create instances of UNO services, US-C, US-D, and US-E?
Yes.
Can the global UNO services manager create instances of all the UNO services?
As a UNO services manager is just a class that implements a certain UNO interface, if the UNO services manager is implemented as to be able to create instances of a UNO service that isn't registered into the global UNO services manager, that UNO service can't be instantiated from the global UNO service manager. Whether there is such a UNO service manager in fact is another story.
Let's clarify our terms. We call things that can be instantiated from any UNO services manager, 'UNO services', regardless of whether they are registered in the global UNO services manager; we call UNO services registered in the global UNO services manager, specifically, 'global UNO services'.
All right.
In the sample UNO extension, we registered the UNO component, HiUnoExtensionsImplementation, as a global UNO service with the name of 'thebiasplanet.uno.hiunoextensionsunoextension.HiUnoExtensions'. Note, the name is identical with the name of the artifact defined in 'HiUnoExtensions.idl', but that artifact isn't a UNO service itself, but a 'UNO service'-specific UNO service instances factory, as we discussed before.
So, the 'UNO service'-specific UNO service instances factory isn't a UNO services manager?
No, it isn't. It's a front end to the global UNO services manager.
I see.
- 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>
