Uno/Article/ES Understanding Uno
Prefacio
Este articulo esta enfocado en explicar los conceptos basicos de UNO. Este documento no enseña a las personas a programar en UNO. Una vez leida esta pagina, el lector sera apto para entender los documentos de programacion de OpenOffice.org incluye la referencia del IDL.
Sin embargo este documento no intenta en reemplazar o simplifcar la guia de desarrollo, ni sus capitulos sobre UNO: es solo una lista de los puntos mas interesantes para empezar con este. Este documento tampoco es un tutorial para desarrollar componentes de UNO: esto ya ha sido hecho por otros documentos.
Introducción, que es UNO ?
"UNO, por que necesito conocerlo ?" sera la primer pregunta para preguntar cuando se lea este documento. De hecho, UNO es que el modelo de componentes de OpenOffice.org: aunque entendiendo los conceptos basicos es muy importante para comenzar a programar en OpenOffice.org.
Reseña rapida de UNO
Como se dijo anteriormente, UNO es el concepto central dentro de OpenOffice.org por que adminstra todos los objetos internos de OpenOffice.org. Sencillamente, UNO provee una manera de llamar otros objetos sin importar del idioma con el que se ha hecho o en que ambientes de ejecucion (Java / C++ / Python). De hecho el metodo llamado en OOoBasic es traducido dentro de una llamada a UNO a la izquierda del metodo de la implementacion. Otra herramienta de UNO es la de permitir programas externas para tener los objetos de OpenOffice.org usando una conexion atravez de la red.
Considerando todos las capacidades de UNO, entendiendo que es importante para desarrollar nuevos componentes de UNO, pero aun para usar el API de OpenOffice.org, macros o programas externos. Aun en este articulo que esta orientado a futuros desarrolladores de componentes, es siempre importante tener el punto de vista para usar componentes. Este articulo esta compuesto de la primer seccion introduciendo el concepto principal y una segunda seccion presentando el impacto en desarrollo de componentes.
Terminos extraños y uso de abreviaciones
Esta sección sera util para aquellos que no son estan familiarizados con algunos de los terminos de desarrollo. Esto puede tambien ser usado como una referencia para lecturas futuras.
- API (Interfaz de Programación de Aplicaciones): un grupo de metodos y atributos disponibles para el uso de programas o componentes. OpenOffice.org API tambien es conocido como Referencia IDL.
- Binding: para programacion de OpenOffice.org, un binding es una traducción de especificacion IDL dentro de un lenguaje de lenguaje de programación. Un binding incluye algunos metodos dependientes del lenguaje y ayuda a manejar los conceptos de UNO.
- Bridge: este concepto esta ligado intimamente a la nocion de binding. Un bridge para UNO es un codigo que permite un binding a un lenguaje. Desarrollando un bridge implica tener un buen conocimiento de UNO y todos sus mecanismos.
- Component: un componente es un bloque que provee mejoras descritas en su especificación. Una mejor pracitca es intentar de mantener el componente tan independiente como sea posible.
- IDL (Lenguaje de Descripcion de Interfaces): lenguaje de descripcion de especificaciones comunes. este lenguaje es usado para describir los tipos definidos por los componentes. Este lenguaje se convierte en una manera mas especifica al lneguaje, dependiendo en los bindings usados. Los archivos de especificacion generalmente tiene la extension de "
.idl". - Registry: un archivo binario que contiene todas las especificaciones del componente. Hay dos tipos de registries: los tipos que contienen las definiciones de UNO y servicios registros ligados a las especificaciones y la implementacion. Este archivo generalmente tiene la extension de "
.rdb". - SDK (Kit de Desarrollo de Software): is a set of tools and definition files to develop on a program. OpenOffice.org SDK is provided on the OpenOffice.org download page.
- Specification: la descripcion de que codigo debera ser. En UNO, esto contiene que la documentacion muestra dentro de la referencia.
- UNO (Objetos de Red Universal): el modelo de componente de OpenOffice.org. Esto sera mas detallado dentro del articulo.
- URE (UNO Runtime Environment): a subset of OpenOffice.org allowing to develop other UNO-based applications. It can be downloaded on the OpenOffice.org download page.
UNO basicos
Esta secciin se presenta como la idea central de UNO lo cual hace la programacion diferente que otra programacion tradicional. Esta seccion seguira los pasos del desarrollo de componentes, sin embargo esto tampoco puede ser considerado como un tutorial.
Especificacion e Implementacion
Lo primero es lo primero, haciendo la distincion entre especificacion e implementacion es importante. Aun que la nocion sea presente dentro de muchas de las aplicaciones, tienen un significado particular para UNO. En aplicaciones normales, la especificacion son definidos dentro de un document en lenguaje natural. Esto existe dentro de OpenOffice.org y es llamado "especificaciones", pero las especificaciones de UNO son diferentes.
Especificaciones dentro de UNO es un grupo de metodos y propriedades definidos dentro del API. Estan escritas en un lenguaje de programacion comun llamado IDL. Ellos definen los tipos disponibles de otro codigo de UNO.
In order for the component to be complete, it has to contain an implementation of its UNO specifications. This implementation could be written in any of the languages supported by UNO. To make a language available for UNO, a bridge between this language and UNO has to be created. The most common implementation languages are C++, Java and Python, but others are available. For more information on the supported languages, please report to the UDK project page or the Uno wiki page.
As shown by the previous illustration, a component's method call will return to the UNO Runtime Environment. This one will translate the call into an implementation call using the services registries. This illustration doesn't reflect the real UNO component composition. It normally contains:
- a type registry, representing the specification in a binary file
- the implementation usually delivered as a shared library
- the services registry describing the mapping between the specified types and their implementations.
As explained later, the services registry will impose some more constraints on the component development. The component build process will not be explained here, but is detailed in the Java component tutorial.
IDL first approach
In order to understand most of the documents, a new OpenOffice.org developer has to be used to UNO-IDL main notions. The main types in UNO-IDL are services and interfaces. An interface defines a set of methods and attributes whereas a service exports an interface.
As every Object Oriented language, IDL supports inheritance. However, services - which can often be compared to Objects in other languages - do not support multiple inheritance: only the interfaces do. This is a new feature of UNO coming with OpenOffice.org 2.0, but IDL still allows a service to export more than one interface: this has been kept for backward compatibility. Thus the OpenOffice.org API still contains some of these services.
The following snippet is the IDL specification of a simple bank account service. This bank account has balance, maximum and rate attributes.
module org { module openoffice { module bank {
interface XBankAccount {
[attribute] short Balance;
[attribute] short Maximum;
[attribute] double Rate {
set StupidRateException;
};
short giveAmount([in] short iAmount);
short receiveAmount([in] short iAmount);
};
exception StupidRateException {
short MaxRate;
short MinRate;
short WantedRate;
};
service BankAccount: XBankAccount {
create(short iBalance, short iMaximum, double dRate);
};
}; }; };
This specification shows some well-known notions as exceptions, and interfaces. Somewhat this example doesn't show is the specification documentation: the OpenOffice.org IDL reference is generated from javadoc-like comments in these files.
Objetos Remotos
The last important UNO concept that will be explained here is the one of proxy objects. In fact UNO doesn't let client code handle the object instance directly: it creates proxy object in order to establish a bridge between the implementation language and the client code language. This notion can be found in other networking object systems like Corba or ICE.
This principle is illustrated by the above illustration. In fact the object instance is created only once and then proxies are created to access this instance. This way the proxy can be in another language or another UNO Runtime Environment than the real object. However, for a developer, this concept is quite transparent. In some language bindings there are methods like queryInterface() which seem difficult to understand((When I started to understand UNO, this createInterface() was used everywhere in the developer's guide first chapters, but I only understood its use when I studied Corba and the remote objects. As stated in this document, this mechanism will tend to disappear from UNO and is kept for backwards compatibility.)).
With the last version of UNO coming with OpenOffice.org 2.0, these methods have become useless. In fact, these queryInterface() methods were used to fetch one specific interface of a service. Now that a service can export only one interface, this becomes useless because creating the service returns necessarily the right interface reference.
Impactos en programación
This paper doesn't aim at describing the exact steps to create a component. This chapter will only explain some UNO impacts on the implementation. In the next sections, the first one on the language bindings can be useful for every UNO or OOo programmer. However the two other parts are written for UNO components developers.
Lenguajes en Bindings
As stated previously, UNO can be used with many languages. This is possible thanks to UNO bridges and has some impacts on programming. From a UNO user point of view, a binding provides several important things:
- A mapping between UNO and the language types. This includes simple types and complex ones like services, interfaces or singletons.
- Tools to generate code from the IDL specifications. In order to be used in the programming language, the IDL specifications have to be translated. For Java and C++, this can be respectively done by using the
javamakerandcppumakertools. - A set of helper methods and objects, often for component implementation.
- A binding documentation in order to understand its specific notions.
Using a binding is not necessarily simple and it may vary with the languages. For example, the OOoBasic binding is very easy to understand: one of the only difficult things is the difference between the Variant and Object types. The most important bindings documentation is contained in the developer's guide, but others are available on the UDK project home page or on the Uno wiki page.
Registro de metodos
In order to bind the specifications to their implementation, components contains a services.rdb registry. To create this file, there are some methods to add in the component implementation: these are called "Registration methods". Each binding has its own set of registration methods to implement, but the idea is always the same: they return a mapping between the UNO type name and its implementation name.
To know exactly what is to be implemented for the component language, please report to the binding documentation. Afterwards, the services.rdb file is generated by running the regcomp tool against the component library.
La interfaz XTypeProvider
It is important to read the next lines to let the component be handled by OOoBasic. This language doesn't use the same mechanisms to find a method or property in a service. com.sun.star.lang.XTypeProvider is an IDL interface provided with OpenOffice.org and the URE. To have OOoBasic support, this interface has to be implemented by the component, otherwise the following problems could appear:
- the methods
Dbg_Properties,Dbg_MethodsandDbg_SupportedInterfaceswill return nothing - using a method or property of the service will raise an unknown member error.
In fact OOoBasic uses the XTypeProvider interface to find the properties and methods of a service. The same problems can occur when the XTypeProvider is implemented using the wrong types. This latter error seems very odd, but can come very easily when using helpers to implement the XTypeProvider interface in complex designs. For example, consider the following IDL specification:
module org { module openoffice { module test {
interface XA {
[attribute] string name;
};
interface XB: XA {
[attribute] short value;
};
service A: XA;
service B: XB;
}; }; };
The implementation could define a helper to implement A and B common parts. However, if this helper uses a helper to implement XTypeProvider, both A and B services could have the same XTypeProvider implementation if this was not properly done. Thus the following OOoBasic code will fail because the XB properties and attributes are not defined using the XTypeProvider.
[bas]
someB.value = 2;
