eyeos 2 - 123seminarsonly.com · php defininidas por la aplicación. aunque durante todo el...

eyeOS 2.x Manual para desarrolladores

Edición 1.0

1

Índice de contenidos

0. Licencia.............................................................................................4

1. Introducción......................................................................................5

1.1. ¿Qué es eyeOS?.....................................................................5

1.2. El sistema de aplicaciones.....................................................6

2. Funcionamiento................................................................................7

2.1. Estructura del sistema...........................................................8

2.2. Persistencia y base de datos y carpetas personales del usuario......................................................................................................9

3. Entorno de desarrollo.....................................................................11

4. Estudio de los componentes...........................................................12

4.1. Kernel...................................................................................12

4.2. Servicios .............................................................................12

4.3. Librerías...............................................................................13

4.4. Frameworks..........................................................................13

4.5. Bootstrap..............................................................................14

5. Estructura de directorios................................................................16

6. MMap, extern y exec......................................................................18

7. Estructura y funcionamiento de una aplicación..............................21

8. Creando nuestra primera aplicación...............................................24

9. Qooxdoo.........................................................................................27

9.1. Clases de qooxdoo extendidas por eyeOS...........................28

10. Módulos de apliación (execmodules)............................................29

11. User Manager...............................................................................30

12. Proc Manager................................................................................31

13. File System Interface....................................................................32

2

14. Security Manager..........................................................................34

15. Metadatos.....................................................................................36

16. Conversión de documentos de oficina..........................................37

17. Dbus.............................................................................................38

18. NetSync, tiempo real....................................................................39

19. Conexión a base de datos............................................................41

19.1. GenericDAO........................................................................41

19.2. Conexión directa................................................................43

20. Referencias y lecturas recomendadas..........................................45

3

0. Licencia

El contenido de este documento está publicado bajo una licencia Creative

Commons. Reconocimiento - No Comercial – Compartir Igual 3.0 Unported.

Puede ver el texto completo de esta licencia en la siguiente dirección:

http://creativecommons.org/licenses/by-nc-sa/3.0/legalcode

Puede ver un resumen de las condiciones de la licencia en la dirección:

http://creativecommons.org/licenses/by-nc-sa/3.0/deed.es

Usted es libre de:

• copiar, distribuir y comunicar públicamente la obra

• hacer obras derivadas

Bajo las condiciones siguientes

• Reconocimiento — Debe reconocer los créditos de la obra de la manera especificada por el autor o el licenciador (pero no de una manera que sugiera que tiene su apoyo o apoyan el uso que hace de su obra).

• No comercial — No puede utilizar esta obra para fines comerciales.

• Compartir bajo la misma licencia — Si altera o transforma esta obra, o genera una obra derivada, sólo puede distribuir la obra generada bajo una licencia idéntica a ésta

4

http://creativecommons.org/licenses/by-nc-sa/3.0/deed.es

http://creativecommons.org/licenses/by-nc-sa/3.0/legalcode

1. Introducción

El objetivo de este documento es proporcionar los conocimientos necesarios para desarrollar sobre el entorno eyeOS, ser capaz de crear aplicaciones, modificar aplicaciones existentes, desarrollar componentes para el sistema en general y comprender su arquitectura.

La audiencia de este documento debería ser completamente técnica, enfocado especialmente a Analistas y desarrolladores web. Se requieren conocimientos de JavaScript y PHP así como un entendimiento general de cómo funciona el desarrollo web.

1.1. ¿Qué es eyeOS?

eyeOS es un escritorio online que proporciona al usuario un interfaz similar al que podría encontrar en el escritorio de su sistema operativo local. Para el desarrollador, eyeOS proporciona un conjunto de herramientas que le permiten desarrollar aplicaciones para el escritorio online, de una forma similar a como lo harían en un escritorio local.

Aunque eyeOS es un escritorio web, sus aplicaciones no tienen apariencia de aplicaciones web, ni se desarrollan utilizando XHTML o CSS. Las aplicaciones en eyeOS se desarrollan utilizando librerías gráficas en Javascript, que permiten al desarrollador trabajar con conceptos de mas alto nivel, como por ejemplo: ventana, botón, lista... En lugar de trabajar con capas/layers, o XHTML a bajo nivel.

La meta de eyeOS es que tanto el usuario como el desarrollador de aplicaciones, trabajen de una forma similar a como trabajarían en un escritorio local, ocultando así los problemas que derivan del hecho de estar trabajando en un entorno web.

Es importante comprender que eyeOS no es solo un escritorio web para el usuario, sino también para el desarrollador. El enfoque de eyeOS es que no tendría sentido proporcionar al usuario aplicaciones que parecen aplicaciones locales, en un escritorio que también parece el de un sistema operativo tradicional, pero a la vez, no proporcionar al desarrollador un conjunto de tecnologías que le permitan crear estas aplicaciones web ricas, de forma simple y fácil.

eyeOS es ideal para aquellos que quieren proporcionar a sus usuarios un interfaz web con acceso a recursos, pero de forma controlada, con controles de acceso y cuentas de usuario, y que además eventualmente necesiten adaptar el entorno a la imagen de su empresa u organización, o agregar nuevas

5

1.2. El sistema de aplicaciones

Debido a la importancia de que el desarrollo de aplicaciones en eyeOS sea lo mas simple posible, pese a que eyeOS es una página web, se ha desarrollado todo un sistema de aplicaciones que permite a un desarrollador desarrollar con total seguridad que otra aplicación no interfiere con la suya.

En este sentido, es igual que un sistema operativo tradicional, donde cada aplicación se ejecuta por separado, con su proceso, su número que identifica al proceso, y donde cada aplicación puede tener unos privilegios distintos de ejecución.

De esta forma, una aplicación en eyeOS es un componente independiente que utiliza las APIs de eyeOS disfrutando de el entorno de desarrollo RIA que ofrece, y que se puede instalar o desinstalar como una cualquier aplicación en un sistema Linux o Windows.

Cada aplicación, una vez ejecutada, es vista como un proceso por eyeOS y tiene su propio identificador de proceso, como en cualquier sistema operativo real. Es posible, además, definir un conjunto de reglas de seguridad de manera que solo un usuario, o un grupo de usuarios puedan veer, instalar y utilizar esta aplicación.

Tal como se verá mas adelante, el sistema proporciona una API para gestionar las aplicaciones que un usuario está ejecutando, por ejemplo para cerrar una aplicación en ejecución, o ejecutar nuevas aplicaciones. Es gracias a esta API, además, que el sistema es capaz de ejecutar cada aplicación sin que esta interfiera con las otras, y puede además ejecutar múltiples instancias de una misma aplicación.

El sistema se encarga de las operaciones de bajo nivel, como por ejemplo: cuando el usuario cierra una aplicación, su proceso es eliminado automáticamente, de esta forma, el desarrollador no tiene que preocuparse de estos detalles, aunque si lo desea, puede intervenir y modificar los comportamientos por defecto y acciones de bajo nivel de todo el sistema.

6

2. Funcionamiento

Técnicamente, eyeOS es un aplicación web desarrollada en PHP y Javascript. Se utiliza PHP para desarrollar toda la arquitectura en el lado del servidor, mientras que Javascript se utiliza para gestionar el escritorio y las aplicaciones que se visualizan en el navegador web del cliente.

De esta forma, todas las aplicaciones de eyeOS, como por ejemplo la pantalla de login, la de registrarse, o la calculadora, son un conjunto de scripts Javascript y PHP.

Cuando el sistema carga por primera vez, el navegador web del cliente descarga todas las librerías Javascript necesarias, y a continuación comienza a comunicarse con el servidor utilizando AJAX. De esta forma, durante toda la sesión del usuario, solo hay una única carga de página (refresh), el resto de operaciones, se realizan mediante peticiones AJAX.

Cuando el usuario ejecuta una aplicación, el sistema comprueba si el código Javascript de la aplicación ya se ha descargado antes. Si ha sido descargado antes, por ejemplo por que el usuario ya ha utilizado esta aplicación durante su sesión actual, entonces simplemente lo ejecuta de nuevo. Si el código no ha sido descargado antes, entonces lo descarga y lo ejecuta.

De esta forma, en la primera carga de eyeOS, solo se descargan las librerías javascript necesarias para el funcionamiento del sistema, y los ficheros javascript especificos de cada aplicación, se van descargando bajo demanda, cuando son ejecutadas las aplicaciones.

Cuando el usuario ejecuta una aplicación en eyeOS, habitualmente le aparece una ventana visual para interaccionar con esta aplicación. La ventana, está desarrollada utilizando una librería Javascript de alto nivel, llamada qooxdoo, muy similar a GTK, Qt, Java swing, o toolkits similares de desarrollo de interfaces de usuario. Cuando el interfaz de usuario en Javascript necesita realizar alguna operación en el servidor, utiliza las librerías de comunicación para enviar mensajes (que a bajo nivel son peticiones AJAX) a las funciones PHP defininidas por la aplicación.

Aunque durante todo el documento se irá aclarando como funciona eyeOS, es bastante útil disponer ya de una visión general. Podríamos resumir eyeOS a que las aplicaciones, desarrolladas con una serie de librerías en PHP y JavaScript, utilizan un conjunto de API’s proporcionadas por el sistema para realizar sus operaciones.

7

De esta forma, la aplicación se ejecuta en un entorno aislado respecto al resto de las aplicaciones, y como está forzada a pasar por el sistema para realizar cualquier operación, el sistema puede garantizar la seguridad. En ningún caso el desarrollador debería acceder a recursos o información del sistema sin pasar por las API’s del sistema, ya que nadie estaría comprobando los privilegios o la seguridad de las operaciones.

2.1. Estructura del sistema

En eyeOS todo el sistema se dividie claramente entre los componentes que funcionan en el JavaScript, y los que funcionan en el PHP, debido al hecho de que eyeOS finalmente es una aplicación web.

Existe una serie de tecnologías disponibles en el JavaScript para simplificar el desarrollo de aplicaciones y una estructura concreta que hay que seguir para que una aplicación funcione en eyeOS. De igual forma, una vez estamos en el lado del servidor, ejecutándonos en el PHP, tenemos disponibles librerías y API’s para trabajar, de forma que no necesitamos usar funciones nativas de PHP, sino que disponemos de muchas librerías que nos facilitan las cosas.

Es importante tener muy clara esta división del mundo del cliente frente al mundo del servidor. El gráfico anterior podría entonces ampliarse al siguiente:

8

AplicaciónSistema

Tal como se puede observar, las aplicaciones están divididas en dos partes, la parte que se ejecuta en el cliente (navegador web), y la parte que se ejecuta en el php (servidor web). La parte que se ejecuta en el cliente se utiliza para dibujar la interfaz de usuario utilizando javascript, y cuando se necesita hacer alguna operación, por ejemplo: leer la base de datos, se ejecuta la parte en PHP, mediante una petición ajax (xmlhttprequest).

2.2. Persistencia y base de datos y carpetas personales del usuario

En eyeOS todos los componentes son modulares, esto quiere decir que eyeOS está formado por una serie de componentes, por ejemplo el gestor de usuarios. Este a su vez, está dividido internamente en componentes aun mas pequeños, como la API pública del gestor de usuarios, el componente que gestiona la lógico de los usuarios, y el componente que guarda los usuarios en la base de datos y los recupera. A este último componente, que se encarga de guardar los usuarios y recuperarlos se le llama provider.

9

Aplicación

PHPNúcleo de

eyeOS

PHP

Comunicación interna entre scripts PHP, en forma de llamadas a funciones/instancias de clases y llamadas a sus métodos.Peticiones

http vía ajax

Navegador web ejecutando las aplicaciones en JavaScript.

Un provider es la pieza dentro de un componente de eyeOS cuya labor es guardar los datos. Esta modularización nos permite programar todo el sistema de usuarios in preocuparse por la base de datos, de forma que cada vez que se quiere extraer un dato de la base de datos, se utiliza al provider. Así, desarrollando un nuevo provider que en lugar de base de datos, utilice XML, todo seguirá funcionando sin tocar una línea de código ni en las aplicaciones ni en el resto del componente.

Debido a esto, cuando alguien pregunta que donde se guardan los usuarios en eyeOS, no existe una respuesta realmente clara. En realidad, todo depende del provider que se utilice. Por defecto se guardarán una base de datos MySQL. Sin embargo, podría desarrollarse muy fácilmente un provider para Oracle, o para Microsft SQL Server. O incluso sobre algún motor no relacional.

Acerca de los datos del usuario, es decir, los ficheros que tienen en el sistema, se guardan en el sistema de ficheros del servidor. Aunque mas adelante se estudiará a fondo todo el sistema de directorios de eyeOS y donde va cada cosa, lo importante ahora es entender que los ficheros del usuario no van a la base de datos, los credenciales etc, si.

10

3. Entorno de desarrollo

Debido a que las aplicaciónes de eyeOS estan totalmente desarrolladas en PHP y Javascript, cualquier editor de texto y cualquier navegador web es suficiente para empezar a desarrollar aplicaciones en eyeOS.

Sin embargo, un editor de texto comun no dispone de coloreado de sintaxis, indentación o funcionalidades de completado de código y aunque es posible desarrollar sin todo esto, no sería el entorno ideal.

Debido a la complejidad del sistema, aunque eyeOS es una página web, normalmente los desarrolladores de aplicaciones instalan servidores web en su propio sistema, de forma que no tienen que subir los cambios a un servidor externo para probarlos. Un entorno habitual es tener un IDE con soporte para PHP y Javascript, un navegador web avanzado y moderno, y un servidor web local sirviendo el eyeOS. De esta forma, para probar cualquier modificación, basta con refrescar la página, sin necesidad de hacer upload a ningún sitio.

Para disponer de funcionalidades como coloreado de sintaxis, indentación, completado de código, integración con software de sistema de control de versiones, recomendamos NetBeans IDE, un entorno de desarrollo integrado que es código abierto y se puede descargar gratuitamente desde http://netbeans.org, soporta Javascript y PHP, entre otros.

Como navegador web, el recomendado es Firefox, debido a que es software libre, multiplataforma y soporta el uso de extensiones o plugins, que agregan funcionalidades al navegador. Además respeta los estándares web. http://www.mozilla-europe.org/es/firefox/

Para agregarle a Firefox funcionalidades de depurado de código, reporte de errores, control de flujo y otras muchas funcionalidades necesarias para el desarrollo web, es recomendable tener instalada la extensión firebug: http://getfirebug.com/http://getfirebug.com/.

Para el servidor web local, donde instalaremos el eyeOS sobre el que se trabajará, se recomienda leer el manual de instalación de eyeOS: http://eyeos.org/installation_manual.pdf, donde se especifica exactamente el software recomendado para ejecutar eyeOS.

Al finalizar la instalación de todo lo necesario se dispondrá básicamente de 3 componentes, el editor de texto netbeans, para crear y modificar código en eyeOS, el servidor web para ejecutar las modificaciones, y el servidor web, para visualizar eyeOS.

11

http://eyeos.org/installation_manual.pdf

http://getfirebug.com/http://getfirebug.com/

4. Estudio de los componentes

Durante todo el texto, se ha nombrado mucho que hay una API disponible para la parte PHP de las aplicaciones, que hay una serie de componentes dentro del lado PHP, etc. Sin embargo, no se ha aclarado como son estos componentes exactamente.

Realmente, el sistema tiene 6 partes diferenciadas entre si, que son:

1. Kernel

2. Servicios

3. Librerias

4. Frameworks

5. Bootstrap

6. Apliaciones

Cualquier módulo dentro de eyeOS encaja dentro de alguna de estas 6 categorías. Mas adelante se presentará un gráfico de la arquitectura lógica del sistema, que ilustra como interactúan estos 6 tipos de componentes.

Sin embargo, antes es importante explicar como funcionan por separado, y por que existen estas categorías de módulos.

4.1. Kernel

El kernel de eyeOS es el componente que se encarga de gestionar a los demás componentes. En realidad, eyeOS 2.x es una aplicación web, y no existe un kernel como tal, como en un sistema operativo, sino que el kernel, es el componente central, quese encarga de gestionar la ejecución del resto de componentes que forman el ‘motor’ de eyeOS. Es como la pieza que unifica el motor. En realidad, para el desarrollador, el kernel es un componente transparente, que no necesita interactuar con el directamente, por lo que su estudio no tiene demasiado interés.

4.2. Servicios

Los servicios son componentes del sistema, que son completamente

12

necesarios para que el propio eyeOS funcione, y que gestionan alguna parte interna del propio funcionamiento de eyeOS. Por ejemplo, un componentes que se encarga de gestionar los usuarios, sería un servicio. Un componente que se encarga de extraer ficheros zip, no lo sería. El motivo es que el segundo, el que extrae ficheros zip, no es imprescindible para el funcionamiento de eyeOS, ni tampoco gestiona nada interno del propio eyeOS, simplemente es una librería mas que está disposición del desarrollador.

La mayoría de servicios se estudiarán en profundidad y por separado mas adelante, pero algunos ejemplos son el gestor de procesos o el gestor de usuarios, por que ambos son componentes imprescindibles que gestionan apartados internos del propio eyeOS.

Todos los servicios disponen de una API pública accesible desde las aplicaciones, de forma que el desarrollador de aplicaciones utiliza los servicios para conseguir que su aplicación interactúe con el sistema, por ejemplo, creando un nuevo usuario a través de la API pública del servicio de usuarios.

4.3. Librerías

Las librerías son pequeños componentes del sistema, que normalmente pasan desapercibidos para la aplicación, y que se encargan de proporcionar un entorno seguro y consistente.

Un ejemplo de una librería es el soporte para utf8. Debido a que PHP no dispone de momento de soporte total para utf8, existe una librería en eyeOS que agrega este soporte.

Las librerías son imprescindibles para que el sistema funcione, pero se diferencian de los servicios en que no gestionan nada de eyeOS, sino que están en una capa inferior, proporcionando compatibilidad y seguridad, y asegurándose de que todo el entorno es el correcto para ejecutar eyeOS. Otra librería es por ejemplo la que comprueba si existe soporte para JSON, y sino existe, lo agrega.

4.4. Frameworks

Los Frameworks son los componentes de mas alto nivel en el sistema, es decir, son aquellos que están mas cerca de las aplicaciones, y mas lejos de los detalles de bajo nivel. Un Framework es un componente no imprescindible, que agrega funcionalidades a eyeOS, pero que no realiza operaciones del propio eyeOS, como por ejemplo, gestionar usuarios, ya que eso sería un servicio.

Un Framework sería por ejemplo el componente que se encarga de convertir

13

documentos de oficina, el cual utilizan las aplicaciones, para visualizar y editar ficheros con formatos de oficina.

Otro ejemplo de Framework sería un supuesto Framework para extraer ficheros zip.

El siguiente gráfico ilustra lo explicado:

En el gráfico, las capas mas exteriores, son las mas cercanas a la lógica de negocio, mientras que cuanto mas interiores, son componentes de mas bajo nivel, mas alejados de la lógica de negocio y mas encargados de temas del propio sistema o del entorno.

De esta forma, el desarrollador dispone de una serie de capas que corren bajo su aplicación y le protegen de los detalles de bajo nivel, como la versión de php, o los módulos instalados, intentando que la aplicación se centre solo en la lógica de negocio.

4.5. Bootstrap

Aunque las aplicaciones se cargan y descargan bajo demanda, es decir, cuando el usario las ejecuta, todas las librerías, servicios y Frameworks deben

14

Aplicación

Framework

Servicio

Librería

ser cargados en cada petición. De forma que cada vez que el usuario ejecuta una aplicación, o bien una aplicación se comunica la parte PHP de la aplicación, todos los componentes están cargados y disponibles.

El bootstrap se encarga de cargar todo el sistema antes de realizar ninguna operación.

Existe un fichero de configuración en eyeos/system/conf/bootstrap/boot.xml que determina el orden en el que se cargan las cosas en el sistema.

La sintaxis es una serie de elementos, similares a:

<element>

<type>library</type>

<name>exceptions</name>

<priority>20</priority>

</element>

Donde cada elemento representa un componente del sistema, en type se especifica el tipo de componente, en name el nombre, y en priority la prioridad de carga. La prioridad de carga es la que modifica el orden en que se cargan los componentes. Por defecto, todos los componentes tienen prioridad 0, y se cargarían todos en orden alfabético. Si queremos que un componente se cargue antes, solo hay que agregarlo, y darle mas prioridad que 0.

15

5. Estructura de directorios

Es importante poder localizar los componentes dentro de eyeOS, así como saber donde están los ficheros de configuración y que orden sigue todo el sistema.

Si entramos a ver los ficheros que componen eyeOS, veremos que en el primer nivel, tenemos solo index.php, settings.php y un directorio llamado eyeos.

Settings.php es un fichero de configuración, pese a ser un script php. Dentro tiene una serie de constantes que se pueden modificar y que afectan al comportamiento de eyeOS. Por ejemplo, el conector a la base de datos se configura aquí, así como otras muchas cosas. En el manual de instalación se dan instrucciones para modificar este fichero.

Index.php es el index de eyeOS, es el fichero con el que se comunicará todo eyeOS. Siempre que se hace una petición a eyeOS, se hace a través de este fichero, ya sea para ejecutar una aplicación, o para realizar alguna acción. Siempre todo pasa a través de index.php.

El directorio eyeos, que se conoce en el argot de eyeOS como eyeroot o raíz de eyeOS, es el que contiene toda la estructura de eyeOS, todos los usuarios, y todo lo demás. Dentro de este directorio hay un .htaccess con una regla ‘deny from all’ dentro, de forma que es imposible visitar este directorio desde el navegador. Solo se puede visitar index.php.

Dentro del directorio de eyeos, existe el siguiente arbol de directorios:

apps/extern/extras/system/tests/users/workgroups/

apps/ dentro de apps se encuentran las aplicaciones, con un directorio por aplicación, y siendo el nombre del directorio, el nombre de la aplicación, por ejemplo, la aplicación calculator, estaría dentro de eyeos/apps/calculator.

extern/ debido a que sólo el fichero index.php es accesible desde el exterior, es decir, visitable por el navegador, eyeOS debe disponer de alguna manera de que el navegador coja los ficheros JavaScript, CSS, imágenes, etc. Todos los recursos que deben ser accesibles por el navegador, están en extern. Cuando index.php recibe una petición tipo index.php?extern=fichero.js, lee el contenido de fichero.js, dentro de extern/ y lo devuelve al navegador, de forma que puede cargarlo. Esto se estudia en profundiad mas adelante.

extras/ todos los scripts y ficheros necesarios para instalar o configurar eyeOS, 16

pero que no son necesarios para que eyeOS funcione, están en este directorio. Por ejemplo, los ficheros SQL para que el administrador cree la base de datos la primera vez están en extras, sin embargo, después de eso, no sirven para nada mas.

system/ el directorio system contiene todos los componentes del sistema, tratados anteriormente, excepto las aplicaciones, que están en apps/. Dentro del directorio system tenemos Frameworks, donde están los Frameworks, bootstrap/ que contiene el bootstrap, conf/ que contiene configuraciones generales del sistema que el administrador puede modificar y kernel/ que contiene dentro las librerías y los servicios.

tests/ contiene los test unitarios del sistema, no tiene ningún interés para el desarrollador de aplicaciones.

users/ contiene los ficheros de todos los usuarios, existe un directorio por cada usuario. Por ejemplo, si el usuario ‘john’ tendría el directorio en eyeos/users/john/, dentro hay todas las configuraciones y ficheros del usuario.

workgroups/ contiene los grupos de trabajo de los usuarios. Si un usuario crea un grupo llamado ‘migrupo’, el directorio será: eyeos/workgroups/migrupo.

17

6. MMap, extern y exec

Dentro del funcionamiento interno de eyeOS, antes de empezar a desarrollar aplicaciones, hay 3 conceptos que hay que comprender, y por eso tienen un capitulo aparte para ellos solos. MMap es un servicio, Extern es un servicio, y exec es una función en javascript.

Tal como hemos visto en el capítulo 5, todas las peticiones a eyeOS pasan a través de index.php, siempre. Eso significa, que index.php realiza una acción u otra, según el tipo de petición que recibe. A index.php se le pueden pasar parámetros por get o post, y según lo que recibe, hace una acción u otra. El mejor ejemplo para entener esto es una web. Imaginemos una web que tiene 4 secciones, y que para ver una sección se hace lo siguiente:

www.ejemplo.com/index.php?seccion=primera

Y que se puede modificar la url, para ponga seccion=segunda, y asi sucesivamente. Index.php según lo que reciba mostrará una sección u otra. eyeOS funciona de la misma forma, todas las peticiones le llegan a index.php, pero dependiendo de las variables get y post que le lleguen, hará una cosa u otra.

Por ejemplo, para ver la pantalla de login, basta con visitar index.php a secas. Mientras que para ver una imagen que está en extern, tal como veremos a continuación, se hace mediante index.php?extern=imagen.jpg. MMap es el servicio del sistema que se encarga de identificar que tipo de petición es, y de ejecutar un componente u otro de eyeOS. MMap funciona con un sistema de plugins, de forma que MMap tiene un plugin para cada tipo de petición que es capaz de gestionar.

Por ejemplo, hay un plugin que dice que si la petición no tiene nada por get ni post, es decir, se ha visitado la web sin pagar ninguna variable, entonces se muestra la pantalla de login. Hay otro plugin, que dice que si hay una variable get llamada extern, entonces lee el contenido del fichero dentro de extern y lo devuelve al navegador. En eyeOS existen otros tipos de peticiones, por ejemplo, cuando se quiere ejecutar una aplicación, se hace una petición a index.php, pasándole el nombre de la aplicación que se quiere ejecutar y el checknum (número que identifica a la aplicación) de la aplicación que la está ejecutando. Es decir, algo así:

http://www.ejemplo.com/index.php?getApplication=calculator&checknum=570515413&args=null

Esto ejecutaría la calculadora. Index.php llama a MMap, que recorre todos sus plugins, buscando quien puede gestionar una petición de ese tipo, encuentra que hay un plugin que ejecuta aplicaciones que entiende la petición, y le pasa el control de ejecución, este plugin de MMap ejecuta la aplicación, recoge el

18

http://www.ejemplo.com/index.php?seccion=primera

Aquí se cargan en memoria todos los componentes, incluido MMap.

Paso 1

Paso 2

Index.phpBootstrap

Aquí MMap encuentra cual es el plugin adecuado, y lo ejecuta, el cual procesará la petición.

MMap

Existen otros tipos de mensajes, por ejemplo, cuando una aplicación vía AJAX quiere comunicarse con el PHP para realizar una acción, por ejemplo, leer la base de datos. La mayoría de estas peticiones son transparentes al desarrollador y no necesita entenderlas para crear aplicaciones. Sin embargo, comprender que todas las peticiones van a index.php y que MMap luego decide que se hace con cada una, es importante para comprender el sistema.

El flujo de ejecución sería el siguiente:

19

Exec es una función disponible en JavaScript, a través del objeto ‘eyeos’. El objeto ‘eyeos’ en javascript lo utilizan las aplicaciones para acceder a funciones básicas del sistema, por ejemplo, ejecutar aplicaciones.

Una aplicación puede llamar desde el javascript, en cualquier momento, a la función exec de la siguiente manera:

eyeos.execute(‘nombreapliacion’, checknum, args);

El primer argumento, es el nombre de la aplicación a ejecutar, el segundo argumento, es el identificador de proceso de la aplicación actual, y el tercero los parámetros que debe recibir la aplicación al ser ejecutada, que pueden ser null o directamente podemos omitirlos. Cuando se ejecuta esa función, veremos aparecer la ventana de la aplicación ejecutada en el escritorio. Internamente, se ha creado un nuevo tag <script>, que se ha agregado al header de la página, y que apunta a:

http://www.ejemplo.com/index.php?getApplication=nombreapliacion&checknum=570515413&args=null

Entonces, esta petición llega a index.php, que la pasa a MMap, el cual encuentra que el plugin que puede gestionarla es el plugin de ejecución de aplicaciones. Se ejecuta el plugin de ejecución de aplicaciones, se inserta un nuevo proceso en la tabla de procesos del usuario, se lee el contenido javascript de la aplicación, y se vuelve al navegador, que al ejecutarlo, dibuja la interfaz gráfica de la aplicación.

20



7. Estructura y funcionamiento de una aplicación

Hasta ahora se ha visto el funcionamiento del sistema y como una aplicación está partida en dos partes, una con el javascript que representa el interfaz de usuario, y otra con el PHP y la lógica de negocio, es decir, la lógica de la aplicación.

Una aplicación es un directorio dentro de eyeos/apps/, llamado como el nombre de la aplicación digamos por ejemplo, ‘test’. Nuestra aplicación ‘test’, estará compuesta por un directorio en eyeos/apps/test/. Dentro de ese directorio, tiene que haber al menos dos ficheros, uno llamado test.js y otro llamado test.php.

El fichero test.js debe tener el código javascript del interfaz de usuario, y test.php la lógica de negocio. En realidad, el fichero php, dentro tiene una serie de funciones, que pueden ser llamadas desde test.js, mediante ajax.

Cuando javascript llama a una función del php, tiene la posibilidad de pasar parámetros, el sistema se encarga de encapsularlos y que lleguen al servidor etc. Si la función php devuelve datos, estos llegarán al javascript que inicio la petición.

Todo esto se hace mediante la función callMessage, que está en el objeto ‘eyeos’, igual que execute, y la sintaxis es la siguiente:

eyeos.callMessage(checknum, ‘nombrefuncion’, args, function(e) {

alert(e);

});

Donde el primer argumento, es el checknum de la aplicación actual, nombrefuncion es el nombre de la función del fichero .php de la aplicación que se quiere ejecutar, args son los argumentos que recibirá la función, y finalmente, definimos una función que se ejecutará cuando termine la petición, a esta función se la conoce como callback. Nuestro callback lo unico que hace es hacer un alert de lo que devuelva el php.

Los ficheros javascript y php de la aplicación (en nuestro caso test.js y test.php) deben tener una estructura concreta para que la aplicación funcione.

En el caso de test.js, debería ser algo así:

21

}

?>

Definimos una clase abstracta, es decir, que no puede ser instanciada, llamada testApplication, que extiende de EyeosApplicationExecutable, mas adelante en el capítulo de execmodules veremos por que extendemos de esa clase, y que nos proporciona. Si quisieramos agregar alguna función php a nuestro fichero php para que el javacript pudiese ejecutarla, bastaría con agregarla en forma de método publico y static dentro de esa clase, algo así:

public static function ejemplo(){

}

Y ahora, ‘ejemplo’ sería un nombre de función válido para ser llamada desde el javascript utilizando callMessage.

23

8. Creando nuestra primera aplicación

Para practicar un poco todo lo explicado, vamos a desarrollar una aplicación que le pide la hora actual al servidor, mediante un botón en el interfaz gráfico que pone ‘obtener hora del servidor’.

El fichero javascript sería el siguiente:

function horaremota_application(checknum, pid, args) {

var app = new eyeos.application.Horaremota(checknum, pid);

app.drawGUI();

}

qx.Class.define("eyeos.application.Horaremota", {

extend: eyeos.system.EyeApplication,

construct: function(checknum, pid) {

arguments.callee.base.call(this,"Horaremota", checknum, pid);

},

members: {

drawGUI: function() {

var mainWindow = new eyeos.ui.Window(this, tr("Hora remota"), 'index.php?extern=/images/16x16/apps/accessories-calculator.png');

mainWindow.setLayout(new qx.ui.layout.VBox());

mainWindow.setAllowMaximize(false);

mainWindow.open();

var display = new 24

qx.ui.basic.Label("").set({

allowGrowX: true,

allowGrowY: true,

textAlign : "right",

font: "bold",

decorator: "main"

});

mainWindow.add(display);

var b2 = new qx.ui.form.Button("Obtener hora remota");

b2.addListener('click',function() {

eyeos.callMessage(this.getChecknum(), 'obtenerHora', null, function(hora) {

display.setContent(hora);

}, this);

}, this);

mainWindow.add(b2);

}}});

Y el fichero PHP sería el siguiente:

<?php

abstract class HoraremotaApplication extends EyeosApplicationExecutable {

public static function obtenerHora() {

return date('l jS \of F Y h:i:s A');

}

}

?>

En nuestro caso se ha creado un directorio en apps/ llamado ‘horaremota’ y

25

dentro dos ficheros ‘horaremota.js’ y ‘horaremota.php’. Ambos ficheros siguen la estructura básica explicada en el capítulo anterior. En el fichero javascaript se ha programado el interfaz de usuario, y en el fichero php se ha definido la única función del PHP de la aplicación que se ejecutará desde el javascript, usando callMessage. El código de la aplicación en javascript está programado usando una librería gráfica de javascript llamada qooxdoo. Qooxdoo permite desarrollar interfaces gráficas de forma sencilla utilizando javascript en lugar XHTML y CSS. En qooxdoo en lugar de preocuparnos por capas, layers, divs, etc se trabaja con Windows, buttons, y demás elementos que se insertan en la ventana. En el siguiente capítulo se trata a fondo qooxdoo y como funciona.

26

9. Qooxdoo

Tal como hemos visto en el capítulo anterior, qooxdoo es una librería gráfica para crear interfaces de usuario similar a como se haría en una aplicación de escritorio utilizando librerías como Qt, Gtk o Swing.

Normalmente, las aplicaciones web se desarrollan usando XHTML, css y tecnologías similares, sin embargo, el enfoque de qooxdoo es que el desarrollador desarrolle una interfaz similar a como sería una interfaz de escritorio. Qooxdoo es un proyecto de sofware libre independiente de eyeOS, disponible en:

http://qooxdoo.org/

Sin embargo, eyeOS ya lo incluye sin que el desarrollador tenga que descargar ni agregar nada. Todas las aplicaciones de eyeOS están desarrolladas utilizando esta librería gráfica. Es imprescindible leer el tutorial de qooxdoo para poder desarrollar y entender las librerías.

Podríamos entonces resumir el desarrollo de una aplicación a crear el interfaz gráfico en javascript usando qooxdoo y llamar a las funciones del fichero php de la aplicación que se necesiten, desde las cuales se pueden utilizar llamadas a servicios o frameworks.

Qooxdoo está completamente orientado a objetos, y permite definir clases, crear interfaces (interfaces de POO) y disponer de herencia en el propio javascript.

Por defecto, qooxdoo incluye una gran cantidad de clases que el desarrollador puede utilizar para desarrollar su aplicación.

Existe una referencia de todas las clases de qooxdoo, con buscador, aquí:

http://demo.qooxdoo.org/current/apiviewer/

El manual de qooxdoo puede leerse aquí: http://qooxdoo.org/documentation/0.8

Qooxdoo está pensando como sistema de desarrollo de aplicaciones con un compilador en python que agrupa los scripts y una serie de utilidades para el desarrollador, en el caso de eyeOS solo utilizamos qooxdoo como librería gráfica, el desarrollador ya tiene todas las clases de qooxdoo cargadas en el navegador cuando se ejecuta su aplicación, y solo debe preocuparse de entender como funcionan los widgets de qooxdoo, los eventos, y como interactuar con el interfaz.

Un ejemplo de esto se puede ver en el capítulo anterior, donde se crea una ventana con un botón y una caja de texto, se agrega un listener al botón, para

27

http://qooxdoo.org/documentation/0.8

http://demo.qooxdoo.org/current/apiviewer/

http://qooxdoo.org/

detectar cuando alguien hace click en el, y cuando se hace click, se llama al servidor, utilizando callMessage, y se modifica la caja de texto con el valor devuelto por el PHP.

9.1. Clases de qooxdoo extendidas por eyeOS

Aunque en eyeOS se utilizan las clases de qooxdoo para desarrollar interfaces de usuario, por ejemplo, qx.ui.button, para dibujar un botón, existen algunos casos especiales donde eyeOS ha extendido las clases de qooxdoo, creando propias con funcionalidad agregada.

Este es el caso por ejemplo de eyeos.ui.Window que extiende qx.ui.Window. El problema reside en que el desarrollador de aplicaciones que hace:

myWindow = new qx.ui.Window(); y consigue una ventana, ahora tiene que insertarla en algún sitio, según la arquitectura de qooxdoo, todos los widgets deben ser insertados en un padre para ser mostrados. ¿Pero cual es el padre para insertar la ventana y que aparezca en el escritorio? En realidad, es un poco complejo. Para evitar que el desarrollador se tenga que preocupar de esto, se ha extendido qx.ui.Window, creando eyeos.ui.Window, que al ser instanciada y llamar al método open, se inserta automáticamente dentro del escritorio, mostrando en pantalla sin necesidad de que el desarrollador sepa quien es el widget padre de esa ventana.

En la actualidad, un desarrollador normal de apliaciones no debería preocuparse de ningún caso mas aparte del de eyeos.ui.Window, ya que el resto de clases extendidas por eyeOS son para funcionamiento interno o casos muy especificos.

28

10. Módulos de apliación (execmodules)

Hemos visto que se pueden agregar funciones en el php de la apliación, en forma de métodos publicos estáticos, que son llamados desde javascript mediante callMessage. Sin embargo, existen una serie de método que toda aplicación debería tener, por ejemplo, una función ‘close’ en el php que se ejecute al cerrar la aplicación, que sería muy pesado tener que ir rehaciendo cada vez que hacemos una aplicación nueva. Es por eso que en realidad las aplicaciones ya disponen de algunos métodos en el PHP heredados de la clase padre EyeosApplicationExecutable, que pueden ser llamados desde el javascript usando callMessage, igual que cualquier método definido por nosotros.

Esto a la práctica signífica que las aplicaciones ya disponen de un conjunto de funciones PHP disponibles para ser ejecutadas desde el javascript mediante callMessage, aunque el desarrollador no haya definido ninguna en el php de la aplicación.

Estás funciones que vienen por defecto, están en

eyeos/system/Frameworks/Applications/Executables/EyeosModules/,

Por ejemplo, si abrimos:

eyeos/system/Frameworks/Applications/Executables/EyeosModules/ContactsExecModule.php, dentro encontraremos una serie de funciones, que estarán disponibles en nuestra aplicación, para ser ejecutadas mediante callMessage.

Por ejemplo:

public static function getAllContacts($params) {

Si quisieramos ejecutarla desde el javascript, sería mediante:

eyeos.callMessage(checknum, ‘__Contacts_getAllContacts’, params, function());

Es igual que un callMessage normal ,pero en el nombre de la función PHP a ejecutar, le ponemos delante __Contacts_ ya que en este caso, la función estaba en el fichero ContactsExecModule.

Muchas aplicaciones utilizan estas funciones para no tener que ir siempre declarando las mismas funciones genéricas, como por ejemplo una función para obtener todos los contactos o cosas similares.

29

11. User Manager

User Manager (UM) es un servicio de eyeOS que permite que las aplicaciones interactúen con el servicio de usuarios de eyeOS. Algunas de sus funciones incluyen la creación de nuevos usuarios en el sistema, el listado de todos los usuarios, la eliminación de usuarios, etc.

Igual que en el resto de servicios de eyeOS, todas las llamadas son controladas para comprobar los permisos del usuario que ejecuta dicha acción, por ejemplo, un usuario que no sea administrador no podrá crear nuevos usuarios ni eliminar existentes a través de llamadas a UM.

Por ejemplo, podemos usar UM para comprobar si un usuario existe o no:

$exists = false;

try {

$myUManager->getUserByName($username);

$exists = true;

} catch (EyeNoSuchUserException $e) {}

Si el usuario no existe, entonces al hacer getUserByName, saltará una excepción, que provocará que el $exists = true no se llegue a ejecutar nunca.

Debajo de ese bloque, podemos comprobar si $exists es true o false.

También podemos utilizar UM para obtener una lista de todos los usuarios del sistema:

$users = UMManager::getInstance()->getAllUsers();

en $users tendremos un array con objetos, cada objeto representa a un usuario en el sistema. Para ver por ejemplo el username de un usuario concreto, por ejemplo el primero, podriamos hacer:

$username = $users[0]->getName();

30

12. Proc Manager

El gestor de procesos o Proc Manager es un servicio de eyeOS que proporciona una API disponible para las aplicaciones, que permite ejecutar aplicaciones, listar los procesos, cerrar procesos, etc.

Un usuario solo puede listar los procesos pertenecientes a su sesión y no a la sesión de otro usuario.

Proc Manager dispone de un método para obtener el proceso actual (current process), de forma que una aplicación puede pedir su propio proceso, para manipularlo, por ejemplo, cerrarse a si misma.

Los privilegios del usuario, están asociados a cada proceso, de forma que un usuario puede tener aplicaciones corriendo con distintos privilegios, tal como en un sistema operativo tradicional.

Si una aplicación quiere obtener cual es el usuario actual, debe consultar al proc manager para obtener el proceso actual, y entonces de ahí extraer el usuario y los privilegios del proceso.

Por ejemplo:

$currentUser = ProcManager::getInstance()->getCurrentProcess()->getLoginContext()->getEyeosUser();

De esta forma, se consulta al gestor de procesos, se le pide el proceso actual, entonces se le pide el LoginContext, que es el objeto que contiene los privilegios del usuario asociado a ese proceso, y dentro de LoginContext, obtenemos el usuario de eyeOS concreto.

Aunque pueda parecer rebuscado, esta forma de trabajar nos permite operaciones avanzadas, como crear aplicaciones que siempre corran con privilegios de super usuario, o con privilegios mínimos.

Una aplicación puede obtener una lista de procesos consultando al proc manager, por ejemplo:

$processes = ProcManager::getInstance()->getProcessesTable();

De esta manera, se obtiene un array con todos los procesos que tiene el usuario. Cada objeto dentro de ese array, contiene la información del proceso en ejecución, por ejemplo, podríamos obtener el nombre del primer proceso mediante

$procName = $processes[0]->getName();

31

13. File System Interface

A la hora de desarrollar una aplicación, existen diferentes maneras de acceder a ficheros por ejemplo a través de las funciones nativas de PHP. La mayoria de los desarrolladores que han trabajado con el PHP conocen bien file, fopen, readfile, file_get_contents, entre otras funciones de acceso ficheros. Estas funciones puede que funcionen de manera diferente dependiendo de el entorno donde se ejecuta el codigo php, por ejemplo en la documentación oficial de la función file de PHP hay un warning que avisa de que hay casos donde Microsoft IIS devuelve un "SSL: Fatal Protocol Error", y se explica como gestionar este problema, siendo el desarrollador quien tiene que preocuparse.

Al problema de trabajar con los ficheros teniendo en cuenta el entorno y el sistema operativo en concreto, se suma el problema de poder garantizar de alguna manera un nivel de seguridad para los ficheros, como por ejemplo permitir solo a los usuarios de eyeOS que tienen los permisos correctos el acceso a un fichero, permitir la escritura o la lectura dependiendo si el usuario en concreto tiene permisos de lectura o de lectura/escritura, etc.

El entorno de desarrollo eyeOS proporciona una capa de abstracción, llamada FSI (File System Interface), que se encarga de abstraer el desarrollador de los detalles de gestionar de forma correcta y ortodoxa los ficheros, y garantizar que todas las operaciones sobre el sistema de archivos se ejecutan bajo la supervisión de un servicio de seguridad, otra capa de abstracción que veremos mas adelante, capaz de gestionar los permisos de los ficheros y elegir si permitir o no permitir una operación en concreto.

El FSI proporciona al desarrollador una API, capaz de abstraer el desarrollador de los problema de seguridad y consistencia, además es capaz de trabajar con diferentes tipos de ficheros dependiendo de sus URL Schemes (ejemplo: ftp://, http://). Por ejemplo, una ruta del tipo home://~foo/Images/image.jpg será traducida como /var/www/eyeos/users/foo/files/Images/image.jpg, donde foo es el usuario de eyeOS, y /var/www/eyeos es la ruta donde esta instalado eyeOS. Gracias a los schemes, el FSI es capaz de leer y escribir ficheros que están físicamente en el disco duro del servidor, en un servidor ftp, en un punto de montaje de otro dispositivo, en una carpeta compartida a través de diferentes protocolos, etc.

Unas de las principales funciones del FSI es getFile, que toma una ruta como parámetro y devuelve, después de traducir el URL scheme y comprobar los permisos, un objeto de tipo EyeFile. Por ejemplo, si quiero acceder a un fichero que tiene como ruta home://~foo/Images/image.jpg (la ruta puede llegar desde un fileChooser, un doble click en un fichero desde el desktop de eyeOS, etc), la sintaxis es la siguiente:

$file = FSI::getFile("home://~foo/Images/image.jpg");

La API se encargara de traducir la URL Scheme home:// de manera correcta,

32

obtener la ruta real de este fichero, comprobar los permisos, por ejemplo puede que el usuario actual no sea el dueño de este fichero pero si que tenga permisos para leerlo, etc. Si el fichero existe y si los permisos están bien, la función getFile devuelve un EyeFile Object, sobre el que el desarrollador puede trabajar de manera fácil y transparente. Por ejemplo si quiere saber si el objecto $file es un directorio, la sintaxis es la siguiente:

$file->isDirectory();

Si el usuario quiere eliminar el fichero:

$file->delete(true);

En conclusión el FSI es unos de los servicios mas importante de eyeOS, y los desarrolladores deberían acceder siempre los ficheros a través de esta API, de manera que sea el sistema quien se encargue de todos los detalles, de forma que queden trasparentes a los ojos del desarrollador.

33

14. Security Manager

Todos los componentes de eyeOS que realizan operaciones sobre datos o información del sistema, así como acceso a recursos, comprueban los privilegios del usuario que ha ejecutado el proceso, antes de realizar ninguna operación. Los privilegios se comprueban contra una serie de reglas, estilo ACL, que determinan si finalmente el usuario puede o no puede realizar esa acción. El componente en eyeOS encargado de realizar estas comprobaciones, es el Security Manager.

Desde el punto de vista del programador, el Security Manager no tiene mucho interés, sin embargo, es importante comprenderlo para poder entender por que eyeOS deniega ciertas operaciones, o como modificar el sistema para que permita cosas que normalmente no permite, por ejemplo.

Las reglas del Security Manager, están en formato XML en eyeos/system/conf/services/security/SecurityManager.xml, y son un conjunto de policies, que dentro tienen un conjunto de handlers. Una policy, es una regla que se aplica a un tipo de objeto, es decir, a una clase. Normalmente el desarrollador utiliza clases para acceder a los recursos del sistema, y el security manager permite especificar reglas sobre estas clases, por ejemplo, los objetos que representan un fichero, o los objetos que representan un proceso.

La mejor forma de entender las policies, es estudiar la primera que aparece en el fichero:

<policy objectClass="EyeUserFile">

Esta regla se aplicará cuando alguien intente manipular un objeto de tipo eyeUserFile. Este objeto es el que consigue a través de FSI::getFile, cuando se accede a un fichero de un usuario.

Es importante entender que los handlers se procesan de arriba abajo, empezando por el primero, hasta ejecutar el último, el parámetro ‘flag’ de cada handler especifica si se deben continuar evaluando handlers, o no.

El primer handler que tiene esta regla dentro, es:

<handler class="SystemGroupSecurityHandler" flag="sufficient">

<param name="groups" value="admin" />

</handler>

34

Este handler especifica que si el handler SystemGroupSecurityHandler devuelve que el usuario está en el grupo ‘admin’ (nótese el <param que hay dentro del handler), entonces eso ya es ‘sufficient’, es decir, ya no hace falta comprobar nada mas, puede acceder.

El siguiente handler de esta policy, es:

<handler class="SystemGroupSecurityHandler" flag="requisite">

<param name="groups" value="vfs" />

</handler>

En este handler se comprueba si el usuario pertenece al grupo ‘vfs’, el flag requisite indica que si pertenece, no significa que tenga acceso, sino que se continuan evaluando handlers, si no pertenece, se termina aquí, y se le deniega el acceso. Tal como dice la palabra, es simplemente un requisito.

A continuación:

<handler class="ShareableObjectSecurityHandler" flag="sufficient" />

Se llama a ShareableObjectsSecurityHandler, con el flag sufficient. De esta forma, si es un fichero compartido (Share), ya es suficiente, y se le permite el acceso.

Y para terminar:

<handler class="EyeosFileSecurityHandler" flag="required" />

Se comprueba contra EyeosFileSecurityHandler, que es un handler básico que comprueba si el fichero es del usuario, de forma que si es suyo, le permite acceder. Al especificar required, si esta regla se cumple, se permitirá el acceso, pero se seguirán evaluando reglas, aunque ya no hay ninguna mas dentro de esta policy.

De esta forma, con todos estos handlers, esta policy permite que cuando se intente acceder a un EyeUserFile, solo te deje si eres admin., si es un fichero compartido, o si el fichero es tuyo, y te deniegue si no perteneces al grupo vfs, que es el grupo en el que deben estar todos los usuarios que acceden a ficheros en eyeOS.

Los handlers que son llamados desde este xml, se definen en eyeos/system/kernel/services/Security/implementations/handlers/. Cualquiera puede crear un nuevo handler, y llamarlo desde un handler, dentro de una policy, en el fichero de configuración.

35

15. Metadatos

En muchas ocasiones se necesita asociar información a un objeto, para cuando mas adelante el objeto se recupere, poder volver a recuperar esa información. Por ejemplo, si tenemos un objeto EyeUserFile, obtenido mediante FSI::getFile y queremos agregarle un rating y poder recuperarlo mas adelante, cuando volvamos a hacer getFile.

A este tipo de información asociada se le llama metadatos.

eyeOS proporciona una API simplificada para el desarrollar, que le permite asociar parejas de llaves/valor a una instancia de una clase, de forma que la próxima vez que vuelva a tener esta instancia, puede recuperar esa información. Esto se usa internamente en el propio eyeOS para los permisos de los ficheros, para los datos personales de un usuario, etc.

Un ejemplo básico para obtener los metadatos asociados a un usuario:

$user = UMManager::getInstance()->getUserById($userId);

Donde $userId es el id del usuario dentro del sistema, con esto llamamos al UM y obtenemos un objeto de tipo eyeUser, que representa al usuario con ese id, y ahora ya podemos obtener los metadatos asociados a este objeto:

$settings = MetaManager::getInstance()->retrieveMeta($user);

En settings tendremos un objeto de tipo metadataInformation, que tiene un metodo get y otro set. Podemos obtener un metadato concreto así:

$firstName = $settings->get('eyeos.user.firstname');

Por ejemplo, para obtener el nombre del usuario.

36

16. Conversión de documentos de oficina

La API de conversión de documentos de oficina permite al desarrollador convertir documentos de oficina entre distintos formatos de forma fácil. Por ejemplo, pasar un XLS a ODS, un DOC a ODT, un PPT a muchos PNG, un XLS a XHTML o un DOC a XHTML.

Uno de los usos principales del conversor es convertir documentos de Microsoft Office, o de OpenOffice a formato XHTML, para que puedan ser visualizados por el navegador sin necesidad de instalar ningún plugin.

Uno de los pasos del manual de instalación de eyeOS es instalar un OpenOffice en el servidor y ejecutarlo en forma de servidor. La API de conversión de documentos se conecta a este OpenOffice y le pide conversiones de documentos.

El conversor de documentos de oficina solo necesita dos parámetros. El fichero a convertir y un formato de destino, y como valor de retorno devuelve una ruta a un fichero temporal, que está en el formato deseado. Ese fichero temporal puede copiarse a otro sitio, o simplemente mostrarse por pantalla.

Un ejemplo:

$myConverter = new Converter();

$path = $myConverter->Convert($filepath, 'HTML (StarWriter)');

No importa si $filePath es un path a un fichero doc, odt, xls, o lo que sea, simplemente el Convertidor de documentos se conectará a OpenOffice y hará la conversión.

El conversor de documentos de oficina, como el resto de componentes de eyeOS utiliza el security manager para comprobar si hay privilegios para leer el fichero que se intenta convertir.

El tiempo que tarde en realizarse la conversión depende de la velocidad de procesado del servidor.

37

17. Dbus

Dbus es una tecnología disponible en el lado javascript de las aplicaciones, proporciona un canal de comunicación común a todas las aplicaciones, donde cualquier aplicación puede enviar un mensaje y cualquier aplicación leerlo. Su principal misión es la comunicación de las aplicaciones entre si en el javascript. Por ejemplo, cuando el uploader de ficheros termina de subir un fichero a un directorio, envía un mensaje por el dbus informando que ha creado ese fichero ahí, por si hay algún gestor de ficheros abierto en ese directorio, que actualice y muestre el fichero nuevo. Esta tecnología se utiliza para muchísimas cosas internamente en el escritorio de eyeOS.

La arquitectura está basado en eventos, de forma que si quieres enviar un nuevo mensaje al dbus, simplemente lo envías, y si quieres recibir eventos del dbus, agregas un listener al dbus y un callback que se ejecuta cuando el mensaje es recibido. Para evitar sobrecargas, todos los mensajes en el dbus tienen un ‘type’ que es como una etiqueta que los cataloga, y cuando escuchamos mensajes en el dbus, solo escuchamos por los types que nosotros queramos, no todos los mensajes.

Un ejemplo del uploader de ficheros enviando un mensaje al dbus:

var bus = eyeos.messageBus.getInstance();

bus.send('upload', 'uploadFinished');

Primero se obtiene una instancia del bus de mensajes, y luego se envía el mensaje uploadFinished, con el ‘type’ upload. De esta forma, solo lo recibirán quienes tengan un listener hacía el ‘type’ upload.

Este mensaje en el dbus puede ser capturado así:

bus.addListener('eyeos_upload_uploadFinished', function() {

alert(‘mensaje nuevo!’);

}, this);

en doc/dbus.txt existe documentación de los mensajes a dbus y su ‘type’ que envían las aplicaciones base de eyeOS.

38

18. NetSync, tiempo real

Debido a que eyeOS puede ser usado en el mismo servidor simultáneamente por multiples usuarios, y que a su vez, los usuarios pueden enviarse invitaciones de amistad, entre muchas otras cosas, eyeOS dispone de un mecanismo para que cuando un usuario efectúa una acción, otros usuarios pueden ser notificados en tiempo real, es decir, sin necesidad de que hagan click en actualizar.

Http es un protocolo de conexión no-persistente, en el que el cliente se conecta al servidor, realiza peticiones y se desconecta, sin que el servidor pueda contactar con el hasta que el cliente vuelva a realizar una petición. El problema es que si un usuario se conecta y hace una petición, que afecta a un tercer usuario, este tercer usuario no podrá ser notificado (visualmente, por ejemplo) hasta que no realice otra petición, lo que normalmente suele ser, hasta que no refresque la página.

Algunas páginas web han desarrollado un mecanismo mediante el cual una petición ajax se ejecuta de forma constante cada cierto tiempo, pidiendo si hay notificaciones pendientes. El problema de este método (conocido como http polling) es que consume muchos recursos en el servidor con peticiones inútiles, y que consume mucho ancho de banda, debido a que hay peticiones continuamente.

EyeOS utiliza un sistema mucho mas avanzado para lograr notificaciones en tiempo real. En primer lugar, en el servidor se instala un servidor de cola de mensajes, llamado ActiveMQ, el cual es un daemon en el que se pueden dejar mensajes en un sistema de colas, y cualquiera que esté suscrito a esa cola, lo recibirá. Muy parecido a un chat pero interno y entre aplicaciones. Para comunicar el navegador con este servicio de colas, se utiliza un Proxy (kaazing) que traduce las peticiones http del navegador al protocolo que entiende ActiveMQ.

Para evitar tener que estar haciendo peticiones periódicamente a este Proxy, pidiendo al ActiveMQ si hay mensajes, se simula una conexión persistente al ActiveMQ a través de dicho Proxy, mediante una petición http que nunca termina, y por la cual vamos recibiendo los mensajes.

Utilizando esta tecnología eyeOS proporciona al desarrollador un mecanismo simplificado, llamado NetSync, para mandar un mensaje al Dbus de otro usuario, de forma que el otro usuario lo recibirá en su dbus, ejecutando los listeners que haya para ese mensaje, en tiempo real.

Como la API de Dbus ya la hemos visto, solo hace falta ver como utilizar NetSync para enviar un mensaje a otro usuario.

var netSync =

39

var message = new eyeos.netSync.Message({

type: 'Playground',

name: 'test',

data: {

test1: 'test',

test2: 'test2'

},

to: 'eyeID_EyeosUser_root'

});

netSync.send(message);

En este ejemplo, se obtiene en primer lugar una instancia del objeto netSync, luego se crea un objeto message que finalmente se envía mediante NetSync. El objeto message contiene dentro la información del mensaje: el ‘type’, el nombre, a quien va dirigido, y los datos asociados al mensaje.

El usuario al que va dirigido se especifica utilizando el id de usuario, no su username.

40

19. Conexión a base de datos

eyeOS internamente funciona por defecto con el motor de base de datos MySQL, aunque utiliza una capa de abstracción que le permite funcionar con cualquier motor de base de datos SQL estándar.

Si una aplicación necesita también conectarse a la base de datos, para crear sus propias tablas y almacenar información en ellas, tiene dos formas de hacerlo.

La primera, es mediante una conexión normal a la base de datos, eyeOS proporciona una serie de métodos para obtener una conexión a la base de datos en cualquier momento.

La segunda manera, es utilizando GenericDAO, una API avanzado de eyeOS que permite al desarrollador no tener que preocuparse por SQL.

19.1. GenericDAO

GenericDAO es una API simplificada que pueden utilizar los desarrolladores de aplicaciones y que se utiliza internamente en todo el sistema.

Para funcionar, el GenericDAO necesita TransferObjetcs, un TransferObject es una clase que representa a una tabla en la base de datos. Por ejemplo, supongamos una tabla en la base de datos con 2 campos, username y password, llamada usuarios.

El transferObject para esta tabla sería:

class usuariosTO {

private $username;

private $password;

public function getPassword() {

return $this->password;

}

public function setPassword($password) {

$this->password = $password;41

}

public function getUsername() {

return $this->username;

}

public function setUsername($username) {

$this->username = $username;

}

}

Como se puede observar, la clase usuarios tiene un atributo por cada campo de la tabla, y un método get y set por cada atributo. De esta forma, Decimos que la clase usuariosTO representa a la tabla usuarios, y que GenericDAO puede utilizar está clase para gestionar la tabla usuarios.

Para trabajar con este transferObject y GenericDAO, se utiliza el transferObject como si fuese la tabla, para comunicarse con el GenericDAO, es decir, por ejemplo, si queremos crear un nuevo usuario, simplemente rellenamos el transferObject (sus dos atributos), y se lo pasamos al método create de GenericDAO.

Para obtener una instancia de GenericDAO, hay que pedirla al storage manager, veamos un ejemplo.

$this->dao = StorageManager::getInstance()->getHandler('SQL/EyeosDAO', array('prefix' => 'mail'));

$usersTO = new usuariosTO();

$usersTO->setUsername('john');

$usersTO->setPassword('12345');

$this->dao->create($usersTO);

De esta manera, utilizamos el transferObject que hemos definido, que representa a la tabla usuarios, lo rellenamos en memori, y se lo pasamos al GenericDAO, y le decimos create. Al hacerlo, GenericDAO extrae el nombre de la tabla del nombre de la clase del transferObject, eliminado el TO del final, en este caso, queda ‘usuarios’.

42

Luego genera una sentencia SQL recogiendo el contenido de los atributos, en este caso username y password, y la ejecuta.

GenericDAO proporciona un método para leer entradas ya existentes en la tabla, y devolver un transferObject ya rellenado con los datos. Para ello, hay que crear un transferObject nuevo, rellenar solo el atributo de la clase que coincide con el campo de la tabla que es el primary key, y ejecutar el método read.

Si suponemos que el campo primary key es el usuario (username), entonces podríamos hacerlo así:


$usersTO = new usersTO();

$usersTO->setUsername('john');

$usersTO = $this->dao->read($usersTO);

Y al terminar, tendríamos $usersTO rellenado con el resto de atributos obtenidos de la base de datos, en este caso, password.

Además, GenericDAO permite obtener todos los registros de la tabla, en forma de array de transferObjects, mediante el método readAll.


$usersTO = new usersTO();

$allUsers = $this->dao->readAll($usersTO);

En $allUsers tendremos un array de transferObjects, todos rellenados con la información de cada usuario de nuestra tabla ficticia ‘usuarios’.

Para borrar un usuario de nuestra tabla, sería igual que para leerlo, rellenando solo el id, en este caso username, pero llamando al método delete, en lugar de read. Para actualizar la información de un usuario, solo habría que hacer un read, cambiar algo, por ejemplo la password, y llamar al método update, pasando nuestro transferObject modificado.

La misión del GenericDAO es ocultar el SQL al desarrollador, que solo se preocupa de la lógica de negocio.

43

19.2. Conexión directa

Para realizar sentencias SQL directamente en la base de datos sin utilizar transferObjects, se utiliza también el GenricDAO, mediante el método send. Esto sirve o bien para no utilizar transferObjects en absoluto, o para utilizarlos, pero utilizar send eventualmente, cuando se quiera hacer una consulta mas compleja, por ejemplo, con subconsultas.


$this->dao->send(‘SQL HERE’);

De esta forma, cualquier aplicación puede ejecutar SQL directamente en la base de datos.

Utilizando el método send del GenericDAO se trabajaría igual que usando msyql_query nativo de PHP por ejemplo, solo que es el GenericDAO quien tiene los parámetros de conexión a la base de datos, y quien realiza el mysql_connect.

44

20. Referencias y lecturas recomendadas

Para empezar a desarrollar una aplicación, es imprescindible estar en contacto con la comunidad, para obtener ayuda y consejos, puedes escribir en el foro en http://forums.eyeos.org para obtener ayuda e información.

Debido al estado en constante crecimiento de eyeOS 2, es posible que tengas que mirar el código de algunos componentes directamente para entender como van, por ejemplo, si vas a hacer un uso intensivo del GenericDAO, puede que necesites ojear un poco su código cuando tengas dudas muy muy profundas.

No se debe entender eyeOS como una caja negra cerrada, sino como un conjunto de libererías, que puedes ver su codigo y entenderlas, mejorarlas, extenderlas etc.

Para poder desarrollar una aplicación con éxito, es imprescindible además entender bien qooxdoo, no tener solo una idea de lo que es, para ello hace falta leer el manual de qooxdoo aquí: http://qooxdoo.org/documentation/0.8 y aventurarse a ver como están hechas muchas de las aplicaciones que eyeOS tiene. Se puede empezar por calculator o login, que son las mas sencillas.

45

http://qooxdoo.org/documentation/0.8

eyeos 2 - 123seminarsonly.com · php defininidas por la aplicación. aunque durante todo el...

Documents