Traducción: Mono.Addins – Punto de Extensión y Extensiones

Introducción

Este artículo es una traducción del original disponible en [1], las licencias aplicadas al original se aplican a la traducción.

mono-logo

La traducción

Una aplicación basada en Mono.Addins se compone de:

  1. Una aplicación huésped (o un huésped de complementos (add-in)), que contiene varios puntos de extensión (extension points).
  2. Varios complementos, que extienden los puntos de extensión del huesped (host)

Implementando un huesped de complementos

El código inmediatamente inferior es un ejemplo básico de una aplicación que contiene complementos, es decir, hace de huésped de complementos. Esta aplicación ejecuta un conjunto de comandos que pueden ser implementados como complementos (add-in).

   1:  using System;
   2:  using Mono.Addins;
   3:   
   4:  [assembly:AddinRoot ("HelloWorld", "1.0")]
   5:   
   6:  class MainClass
   7:  {
   8:      public static void Main ()
   9:      {
  10:          AddinManager.Initialize ();
  11:          AddinManager.Registry.Update ();
  12:          
  13:          foreach (ICommand cmd in AddinManager.GetExtensionObjects<ICommand> ())
  14:              cmd.Run ();
  15:      }
  16:  }

.csharpcode, .csharpcode pre
{
font-size: small;
color: black;
font-family: consolas, “Courier New”, courier, monospace;
background-color: #ffffff;
/*white-space: pre;*/
}
.csharpcode pre { margin: 0em; }
.csharpcode .rem { color: #008000; }
.csharpcode .kwrd { color: #0000ff; }
.csharpcode .str { color: #006080; }
.csharpcode .op { color: #0000c0; }
.csharpcode .preproc { color: #cc6633; }
.csharpcode .asp { background-color: #ffff00; }
.csharpcode .html { color: #800000; }
.csharpcode .attr { color: #ff0000; }
.csharpcode .alt
{
background-color: #f4f4f4;
width: 100%;
margin: 0em;
}
.csharpcode .lnum { color: #606060; }

Este código muestra declaraciones e inicializaciones que tienen que hacerse en todas las aplicaciones extensibles:

  • El atributo [AddinRoot] aplicado a un ensamblado indica que ese ensamblado es un huésped de complementos. Todos los proyectos que incluyan gestión de complementos tendrán un identificador y una versión.
  • La llamada al método AddinManager.Initialize se encarga de inicializar el administrador de complementos (AddinManager). Ante de realizar cualquier operación con la clase AddinManager hay que realizar esta llamada.
  • Cuando se realiza la llamada al método AddinManager.Registry.Update, el motor de complementos inspeccionará la carpeta donde está alojada la aplicación (y otras carpetas indicadas por el programador) buscando complementos, esto actualizará el registro de complementos (add-in registry) que almacena la información sobre los complementos.
  • La llamada al método AddinManager.GetExtensionObjects se puede entender como una consulta a los puntos de extension. Devuelve una lista de objetos registrados en un determinado punto de extensión.

Para completar el ejemplo anterior deberemos declarar los puntos de extensión.

Declarando puntos de extensión

Los puntos de extensión se declaran como indica el siguiente código:

   1:  using Mono.Addins;
   2:   
   3:  [TypeExtensionPoint]
   4:  public interface ICommand
   5:  {
   6:      void Run ();
   7:  }

El atributo [TypeExtensionPoint] cuando se le aplica a una clase o a un interfaz indica que un punto de extensión acepta objetos de ese tipo. En el ejemplo, hemos creado un punto de extensión para los objetos que implementan el interfaz ICommand.

Implementando un Complemento (add-in)

Un complemento extiende un punto de extensión de la siguiente manera:

   1:  using System;
   2:  using Mono.Addins;
   3:   
   4:  [assembly:Addin]
   5:  [assembly:AddinDependency ("HelloWorld", "1.0")]
   6:   
   7:  [Extension]
   8:  public class HelloCommand: ICommand
   9:  {
  10:      public void Run ()
  11:      {
  12:          Console.WriteLine ("Hello World!");
  13:      }
  14:  }

.csharpcode, .csharpcode pre
{
font-size: small;
color: black;
font-family: consolas, “Courier New”, courier, monospace;
background-color: #ffffff;
/*white-space: pre;*/
}
.csharpcode pre { margin: 0em; }
.csharpcode .rem { color: #008000; }
.csharpcode .kwrd { color: #0000ff; }
.csharpcode .str { color: #006080; }
.csharpcode .op { color: #0000c0; }
.csharpcode .preproc { color: #cc6633; }
.csharpcode .asp { background-color: #ffff00; }
.csharpcode .html { color: #800000; }
.csharpcode .attr { color: #ff0000; }
.csharpcode .alt
{
background-color: #f4f4f4;
width: 100%;
margin: 0em;
}
.csharpcode .lnum { color: #606060; }

Los complementos se desarrollan en ensamblados diferentes, tienen que estar marcados con el atributo [Addin] para ser reconocido como un complemento. Los complementos tienen que indicar a que huesped extienden utilizando el atributo AddinDependency, indicando el id del huesped o complemento y el número de versión.

Mediante la aplicación de la [extensión] atributo a una clase que se declara una nueva extensión del nodo que tipo que se agrega a un punto de extensión. El punto de extensión se determina observando la tipos base e interfaces de la clase. Así que en este ejemplo, la clase implementa la ICommand interfaz, y hay un punto de extensión definida para esa interfaz, por lo que es la extensiónpunto en el que el tipo se registrará. Si una clase implementa varias interfaces, podemos seleccionar el punto de extensión, especificando el nombre del tipo en el atributo, por ejemplo: [Extensión (typeof (ICommand))].

Anuncios

Traducción: Mono.Addins – Localización de Complementos por defecto

Introducción

Este artículo es una traducción del original disponible en [1], las licencias aplicadas al original se aplican a esta traducción.

mono-logo

La traducción

Mono.Addins incorpora un modelo flexible para indicar donde deberían estar los complementos (add-ins). Por defecto, los complementos están en dos rutas:

  • En la carpeta donde está el ejecutable de la aplicación, es decir, dónde está en .exe.
  • En la carpeta ‘addins’, que es la ruta de registro de los complementos.

Por ejemplo, si una aplicación está instalada en ‘/usr/lib/MiAplicacion/inicio.exe’, y la aplicación inicializa el motor de complementos tal que así:

   1:  AddinManager.Initialize("[ApplicationData]/MiAplicacion");

.csharpcode, .csharpcode pre
{
font-size: small;
color: black;
font-family: consolas, “Courier New”, courier, monospace;
background-color: #ffffff;
/*white-space: pre;*/
}
.csharpcode pre { margin: 0em; }
.csharpcode .rem { color: #008000; }
.csharpcode .kwrd { color: #0000ff; }
.csharpcode .str { color: #006080; }
.csharpcode .op { color: #0000c0; }
.csharpcode .preproc { color: #cc6633; }
.csharpcode .asp { background-color: #ffff00; }
.csharpcode .html { color: #800000; }
.csharpcode .attr { color: #ff0000; }
.csharpcode .alt
{
background-color: #f4f4f4;
width: 100%;
margin: 0em;
}
.csharpcode .lnum { color: #606060; }

Entonces los complementos se buscaran por defecto es:

  1. /usr/lib/MiAplicacion
  2. ApplicationData/MiApplication/addins

Incluyendo carpetas de complementos

Se pueden añadir rutas para la búsqueda de complementos utilizando el archivo .addins. Un archivo .addins es una archivo XML que se ve tal que así:

   1:  <Addins>
   2:     <Directory>/alguna/carpeta</Directory>
   3:     <Directory include-subdirs="true">/alguna/carpeta</Directory>
   4:     <Directory>../ruta/relativa/carpeta</Directory>
   5:     <Exclude>alguna/carpeta</Exclude>
   6:  </Addins>

.csharpcode, .csharpcode pre
{
font-size: small;
color: black;
font-family: consolas, “Courier New”, courier, monospace;
background-color: #ffffff;
/*white-space: pre;*/
}
.csharpcode pre { margin: 0em; }
.csharpcode .rem { color: #008000; }
.csharpcode .kwrd { color: #0000ff; }
.csharpcode .str { color: #006080; }
.csharpcode .op { color: #0000c0; }
.csharpcode .preproc { color: #cc6633; }
.csharpcode .asp { background-color: #ffff00; }
.csharpcode .html { color: #800000; }
.csharpcode .attr { color: #ff0000; }
.csharpcode .alt
{
background-color: #f4f4f4;
width: 100%;
margin: 0em;
}
.csharpcode .lnum { color: #606060; }

Cuando un registro está buscando complementos en una carpeta y encuentra un archivo .addins, lo analizará sintácticamente y de manera recursiva buscará en las carpetas declaradas, que a su vez incluirán archivos .addins. La etiqueta Directory se usa para declarar nuevas carpetas, esta búsqueda no es recursiva por defecto, para activar la búsqueda recursiva utilizamos el atributo include-subdirs. La etiqueta Exclude se usa para no buscar en una carpeta determinada, puede ser una ruta o un archivo.

El sistema operativo de 1K-3A: el problema son las aplicaciones

Introducción

El sistema operativo de 1K-3A será una distribución Linux, actualmente es la versión alpha de OpenQbo, distribución de la que estoy esperando una actualización mayor para poder seguir usándola. Mientras tanto, he elaborado una arquitectura deseable de sistema operativo para 1K-3A que tendría la siguiente arquitectura:

linuxos

 

Arquitectura

Tendríamos varios niveles en el sistema operativo, por un lado el kernel de linux y los drivers de dispositivos. Posteriormente el sistema ROS, del que ya he publicado algún que otro artículo en el blog y después una capa de introspección. La capa de introspección nos permite poder utilizar cualquier lenguaje para acceder a los paquetes disponibles en ROS, este es un trabajo arduo y doloroso pero que tendría la contrapartida y gran ventaja de poder utilizar cualquier lenguaje para el que exista el binding. O mejor dicho, es más fácil crear bindings (adaptaciones) de lenguajes de programación para ROS. Así no nos limitaríamos a C,C++ y Python sino además otros lenguajes soportados por el proyecto Gnome. La capa final es la nube (Cloud), es decir, la conexión permanente de nuestro robot a la nube de servicios disponibles en internet.

A %d blogueros les gusta esto: