eyeOS 2.

x
Manual para desarrolladores
Edicin 1.0

ndice de contenidos
0. Licencia.............................................................................................4 1. Introduccin......................................................................................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. Libreras...............................................................................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 aplicacin..............................21 8. Creando nuestra primera aplicacin...............................................24 9. Qooxdoo.........................................................................................27 9.1. Clases de qooxdoo extendidas por eyeOS...........................28 10. Mdulos de apliacin (execmodules)............................................29 11. User Manager...............................................................................30 12. Proc Manager................................................................................31 13. File System Interface....................................................................32 2

14. Security Manager..........................................................................34 15. Metadatos.....................................................................................36 16. Conversin de documentos de oficina..........................................37 17. Dbus.............................................................................................38 18. NetSync, tiempo real....................................................................39 19. Conexin a base de datos............................................................41 19.1. GenericDAO........................................................................41 19.2. Conexin directa................................................................43 20. Referencias y lecturas recomendadas..........................................45

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 direccin:

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

Puede ver un resumen de las condiciones de la licencia en la direccin:

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

Usted es libre de: copiar, distribuir y comunicar pblicamente la obra hacer obras derivadas

Bajo las condiciones siguientes Reconocimiento Debe reconocer los crditos 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, slo puede distribuir la obra generada bajo una licencia idntica a sta 4

1. Introduccin
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 debera ser completamente tcnica, enfocado especialmente a Analistas y desarrolladores web. Se requieren conocimientos de JavaScript y PHP as como un entendimiento general de cmo funciona el desarrollo web.

1.1. Qu es eyeOS?
eyeOS es un escritorio online que proporciona al usuario un interfaz similar al que podra 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 haran 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 libreras grficas en Javascript, que permiten al desarrollador trabajar con conceptos de mas alto nivel, como por ejemplo: ventana, botn, 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 trabajaran 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 tambin para el desarrollador. El enfoque de eyeOS es que no tendra sentido proporcionar al usuario aplicaciones que parecen aplicaciones locales, en un escritorio que tambin parece el de un sistema operativo tradicional, pero a la vez, no proporcionar al desarrollador un conjunto de tecnologas que le permitan crear estas aplicaciones web ricas, de forma simple y fcil. 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 adems eventualmente necesiten adaptar el entorno a la imagen de su empresa u organizacin, 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 pgina web, se ha desarrollado todo un sistema de aplicaciones que permite a un desarrollador desarrollar con total seguridad que otra aplicacin no interfiere con la suya. En este sentido, es igual que un sistema operativo tradicional, donde cada aplicacin se ejecuta por separado, con su proceso, su nmero que identifica al proceso, y donde cada aplicacin puede tener unos privilegios distintos de ejecucin. De esta forma, una aplicacin 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 aplicacin en un sistema Linux o Windows. Cada aplicacin, 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, adems, definir un conjunto de reglas de seguridad de manera que solo un usuario, o un grupo de usuarios puedan veer, instalar y utilizar esta aplicacin. 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 aplicacin en ejecucin, o ejecutar nuevas aplicaciones. Es gracias a esta API, adems, que el sistema es capaz de ejecutar cada aplicacin sin que esta interfiera con las otras, y puede adems ejecutar mltiples instancias de una misma aplicacin. El sistema se encarga de las operaciones de bajo nivel, como por ejemplo: cuando el usuario cierra una aplicacin, su proceso es eliminado automticamente, 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.

2. Funcionamiento
Tcnicamente, eyeOS es un aplicacin 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 libreras Javascript necesarias, y a continuacin comienza a comunicarse con el servidor utilizando AJAX. De esta forma, durante toda la sesin del usuario, solo hay una nica carga de pgina (refresh), el resto de operaciones, se realizan mediante peticiones AJAX. Cuando el usuario ejecuta una aplicacin, el sistema comprueba si el cdigo Javascript de la aplicacin ya se ha descargado antes. Si ha sido descargado antes, por ejemplo por que el usuario ya ha utilizado esta aplicacin durante su sesin actual, entonces simplemente lo ejecuta de nuevo. Si el cdigo no ha sido descargado antes, entonces lo descarga y lo ejecuta. De esta forma, en la primera carga de eyeOS, solo se descargan las libreras javascript necesarias para el funcionamiento del sistema, y los ficheros javascript especificos de cada aplicacin, se van descargando bajo demanda, cuando son ejecutadas las aplicaciones. Cuando el usuario ejecuta una aplicacin en eyeOS, habitualmente le aparece una ventana visual para interaccionar con esta aplicacin. La ventana, est desarrollada utilizando una librera 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 operacin en el servidor, utiliza las libreras de comunicacin para enviar mensajes (que a bajo nivel son peticiones AJAX) a las funciones PHP defininidas por la aplicacin. Aunque durante todo el documento se ir aclarando como funciona eyeOS, es bastante til disponer ya de una visin general. Podramos resumir eyeOS a que las aplicaciones, desarrolladas con una serie de libreras en PHP y JavaScript, utilizan un conjunto de APIs proporcionadas por el sistema para realizar sus operaciones.

Aplicacin

Sistema

De esta forma, la aplicacin se ejecuta en un entorno aislado respecto al resto de las aplicaciones, y como est forzada a pasar por el sistema para realizar cualquier operacin, el sistema puede garantizar la seguridad. En ningn caso el desarrollador debera acceder a recursos o informacin del sistema sin pasar por las APIs del sistema, ya que nadie estara 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 aplicacin web. Existe una serie de tecnologas disponibles en el JavaScript para simplificar el desarrollo de aplicaciones y una estructura concreta que hay que seguir para que una aplicacin funcione en eyeOS. De igual forma, una vez estamos en el lado del servidor, ejecutndonos en el PHP, tenemos disponibles libreras y APIs para trabajar, de forma que no necesitamos usar funciones nativas de PHP, sino que disponemos de muchas libreras que nos facilitan las cosas. Es importante tener muy clara esta divisin del mundo del cliente frente al mundo del servidor. El grfico anterior podra entonces ampliarse al siguiente:

Aplicacin PHP

Ncleo de eyeOS PHP

Navegador web ejecutando las aplicaciones en JavaScript.

Peticiones http va ajax

Comunicacin interna entre scripts PHP, en forma de llamadas a funciones/instancias de clases y llamadas a sus mtodos.

Tal como se puede observar, las aplicaciones estn 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 operacin, por ejemplo: leer la base de datos, se ejecuta la parte en PHP, mediante una peticin 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 pequeos, como la API pblica del gestor de usuarios, el componente que gestiona la lgico 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

Un provider es la pieza dentro de un componente de eyeOS cuya labor es guardar los datos. Esta modularizacin 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 lnea de cdigo 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 guardarn una base de datos MySQL. Sin embargo, podra desarrollarse muy fcilmente un provider para Oracle, o para Microsft SQL Server. O incluso sobre algn 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 aplicacines 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, indentacin o funcionalidades de completado de cdigo y aunque es posible desarrollar sin todo esto, no sera el entorno ideal.

Debido a la complejidad del sistema, aunque eyeOS es una pgina 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 modificacin, basta con refrescar la pgina, sin necesidad de hacer upload a ningn sitio. Para disponer de funcionalidades como coloreado de sintaxis, indentacin, completado de cdigo, integracin con software de sistema de control de versiones, recomendamos NetBeans IDE, un entorno de desarrollo integrado que es cdigo 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. Adems respeta los estndares web. http://www.mozilla-europe.org/es/firefox/ Para agregarle a Firefox funcionalidades de depurado de cdigo, reporte de errores, control de flujo y otras muchas funcionalidades necesarias para el desarrollo web, es recomendable tener instalada la extensin 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 instalacin de eyeOS: http://eyeos.org/installation_manual.pdf, donde se especifica exactamente el software recomendado para ejecutar eyeOS. Al finalizar la instalacin de todo lo necesario se dispondr bsicamente de 3 componentes, el editor de texto netbeans, para crear y modificar cdigo en eyeOS, el servidor web para ejecutar las modificaciones, y el servidor web, para visualizar eyeOS. 11

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 mdulo dentro de eyeOS encaja dentro de alguna de estas 6 categoras. Mas adelante se presentar un grfico de la arquitectura lgica del sistema, que ilustra como interactan estos 6 tipos de componentes. Sin embargo, antes es importante explicar como funcionan por separado, y por que existen estas categoras de mdulos.

4.1. Kernel
El kernel de eyeOS es el componente que se encarga de gestionar a los dems componentes. En realidad, eyeOS 2.x es una aplicacin 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 ejecucin 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 inters.

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, sera un servicio. Un componente que se encarga de extraer ficheros zip, no lo sera. 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 librera mas que est disposicin del desarrollador. La mayora de servicios se estudiarn 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 pblica accesible desde las aplicaciones, de forma que el desarrollador de aplicaciones utiliza los servicios para conseguir que su aplicacin interacte con el sistema, por ejemplo, creando un nuevo usuario a travs de la API pblica del servicio de usuarios.

4.3. Libreras
Las libreras son pequeos componentes del sistema, que normalmente pasan desapercibidos para la aplicacin, y que se encargan de proporcionar un entorno seguro y consistente. Un ejemplo de una librera es el soporte para utf8. Debido a que PHP no dispone de momento de soporte total para utf8, existe una librera en eyeOS que agrega este soporte. Las libreras son imprescindibles para que el sistema funcione, pero se diferencian de los servicios en que no gestionan nada de eyeOS, sino que estn en una capa inferior, proporcionando compatibilidad y seguridad, y asegurndose de que todo el entorno es el correcto para ejecutar eyeOS. Otra librera 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 estn 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 sera un servicio. Un Framework sera 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 sera un supuesto Framework para extraer ficheros zip. El siguiente grfico ilustra lo explicado:

Aplicacin Framework Servicio Librera

En el grfico, las capas mas exteriores, son las mas cercanas a la lgica de negocio, mientras que cuanto mas interiores, son componentes de mas bajo nivel, mas alejados de la lgica 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 aplicacin y le protegen de los detalles de bajo nivel, como la versin de php, o los mdulos instalados, intentando que la aplicacin se centre solo en la lgica de negocio.

4.5. Bootstrap
Aunque las aplicaciones se cargan y descargan bajo demanda, es decir, cuando el usario las ejecuta, todas las libreras, servicios y Frameworks deben 14

ser cargados en cada peticin. De forma que cada vez que el usuario ejecuta una aplicacin, o bien una aplicacin se comunica la parte PHP de la aplicacin, todos los componentes estn cargados y disponibles. El bootstrap se encarga de cargar todo el sistema antes de realizar ninguna operacin. Existe un fichero de configuracin 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 cargaran todos en orden alfabtico. 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 estn los ficheros de configuracin 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 configuracin, 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 instalacin 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 peticin a eyeOS, se hace a travs de este fichero, ya sea para ejecutar una aplicacin, o para realizar alguna accin. Siempre todo pasa a travs de index.php. El directorio eyeos, que se conoce en el argot de eyeOS como eyeroot o raz de eyeOS, es el que contiene toda la estructura de eyeOS, todos los usuarios, y todo lo dems. 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 aplicacin, y siendo el nombre del directorio, el nombre de la aplicacin, por ejemplo, la aplicacin calculator, estara dentro de eyeos/apps/calculator. extern/ debido a que slo 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, imgenes, etc. Todos los recursos que deben ser accesibles por el navegador, estn en extern. Cuando index.php recibe una peticin 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, estn en este directorio. Por ejemplo, los ficheros SQL para que el administrador cree la base de datos la primera vez estn en extras, sin embargo, despus de eso, no sirven para nada mas. system/ el directorio system contiene todos los componentes del sistema, tratados anteriormente, excepto las aplicaciones, que estn en apps/. Dentro del directorio system tenemos Frameworks, donde estn 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 libreras y los servicios. tests/ contiene los test unitarios del sistema, no tiene ningn inters 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 tendra 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 funcin en javascript. Tal como hemos visto en el captulo 5, todas las peticiones a eyeOS pasan a travs de index.php, siempre. Eso significa, que index.php realiza una accin u otra, segn el tipo de peticin que recibe. A index.php se le pueden pasar parmetros por get o post, y segn lo que recibe, hace una accin u otra. El mejor ejemplo para entener esto es una web. Imaginemos una web que tiene 4 secciones, y que para ver una seccin 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 segn lo que reciba mostrar una seccin 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 continuacin, se hace mediante index.php?extern=imagen.jpg. MMap es el servicio del sistema que se encarga de identificar que tipo de peticin 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 peticin que es capaz de gestionar. Por ejemplo, hay un plugin que dice que si la peticin 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 aplicacin, se hace una peticin a index.php, pasndole el nombre de la aplicacin que se quiere ejecutar y el checknum (nmero que identifica a la aplicacin) de la aplicacin que la est ejecutando. Es decir, algo as: http://www.ejemplo.com/index.php? getApplication=calculator&checknum=570515413&args=null Esto ejecutara la calculadora. Index.php llama a MMap, que recorre todos sus plugins, buscando quien puede gestionar una peticin de ese tipo, encuentra que hay un plugin que ejecuta aplicaciones que entiende la peticin, y le pasa el control de ejecucin, este plugin de MMap ejecuta la aplicacin, recoge el 18

Existen otros tipos de mensajes, por ejemplo, cuando una aplicacin va AJAX quiere comunicarse con el PHP para realizar una accin, por ejemplo, leer la base de datos. La mayora 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 ejecucin sera el siguiente: Index.php Bootstrap

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

Paso 2 MMap

Aqu MMap encuentra cual es el plugin adecuado, y lo ejecuta, el cual procesar la peticin.

19

Exec es una funcin disponible en JavaScript, a travs del objeto eyeos. El objeto eyeos en javascript lo utilizan las aplicaciones para acceder a funciones bsicas del sistema, por ejemplo, ejecutar aplicaciones. Una aplicacin puede llamar desde el javascript, en cualquier momento, a la funcin exec de la siguiente manera: eyeos.execute(nombreapliacion, checknum, args);

El primer argumento, es el nombre de la aplicacin a ejecutar, el segundo argumento, es el identificador de proceso de la aplicacin actual, y el tercero los parmetros que debe recibir la aplicacin al ser ejecutada, que pueden ser null o directamente podemos omitirlos. Cuando se ejecuta esa funcin, veremos aparecer la ventana de la aplicacin ejecutada en el escritorio. Internamente, se ha creado un nuevo tag <script>, que se ha agregado al header de la pgina, y que apunta a: http://www.ejemplo.com/index.php? getApplication=nombreapliacion&checknum=570515413&args=null Entonces, esta peticin llega a index.php, que la pasa a MMap, el cual encuentra que el plugin que puede gestionarla es el plugin de ejecucin de aplicaciones. Se ejecuta el plugin de ejecucin de aplicaciones, se inserta un nuevo proceso en la tabla de procesos del usuario, se lee el contenido javascript de la aplicacin, y se vuelve al navegador, que al ejecutarlo, dibuja la interfaz grfica de la aplicacin.

20

7. Estructura y funcionamiento de una aplicacin

Hasta ahora se ha visto el funcionamiento del sistema y como una aplicacin est partida en dos partes, una con el javascript que representa el interfaz de usuario, y otra con el PHP y la lgica de negocio, es decir, la lgica de la aplicacin. Una aplicacin es un directorio dentro de eyeos/apps/, llamado como el nombre de la aplicacin digamos por ejemplo, test. Nuestra aplicacin 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 cdigo javascript del interfaz de usuario, y test.php la lgica 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 funcin del php, tiene la posibilidad de pasar parmetros, el sistema se encarga de encapsularlos y que lleguen al servidor etc. Si la funcin php devuelve datos, estos llegarn al javascript que inicio la peticin. Todo esto se hace mediante la funcin callMessage, que est en el objeto eyeos, igual que execute, y la sintaxis es la siguiente:

eyeos.callMessage(checknum, function(e) { alert(e); });

nombrefuncion,

args,

Donde el primer argumento, es el checknum de la aplicacin actual, nombrefuncion es el nombre de la funcin del fichero .php de la aplicacin que se quiere ejecutar, args son los argumentos que recibir la funcin, y finalmente, definimos una funcin que se ejecutar cuando termine la peticin, a esta funcin 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 aplicacin (en nuestro caso test.js y test.php) deben tener una estructura concreta para que la aplicacin funcione. En el caso de test.js, debera ser algo as: 21

function test_application(checknum, pid, args) { var app = new eyeos.application.test(checknum, pid); app.drawGUI(); }

qx.Class.define("eyeos.application.test", { extend: eyeos.system.EyeApplication, construct: function(checknum, pid) { arguments.callee.base.call(this,"test", checknum, pid); }, members: { drawGUI: function() { } } });

El primer bloque, define una funcin llamada test_application que se ejecutar cuando se ejecute la aplicacin. La funcion test_application es el punto de entrada de nuestra aplicacin. Debajo definimos una clase que representa a nuestra aplicacin, por ello, heredamos de eyeos.system.EyeApplication.. Definimos un mtodo llamado drawGUI, y lo ejecutamos desde test_application. Y es en drawGUI donde realmente pintaremos el interfaz de usuario. Esto es lo mnimo que debe tener nuestro fichero javascript, nada mas. Aun no hay ninguna llamada al php ni nada.

Lo mnimo que debe tener nuestro fichero php, es: <?php abstract class testApplication EyeosApplicationExecutable { extends

22

} ?> Definimos una clase abstracta, es decir, que no puede ser instanciada, llamada testApplication, que extiende de EyeosApplicationExecutable, mas adelante en el captulo de execmodules veremos por que extendemos de esa clase, y que nos proporciona. Si quisieramos agregar alguna funcin php a nuestro fichero php para que el javacript pudiese ejecutarla, bastara con agregarla en forma de mtodo publico y static dentro de esa clase, algo as: public static function ejemplo(){ } Y ahora, ejemplo sera un nombre de funcin vlido para ser llamada desde el javascript utilizando callMessage.

23

8. Creando nuestra primera aplicacin

Para practicar un poco todo lo explicado, vamos a desarrollar una aplicacin que le pide la hora actual al servidor, mediante un botn en el interfaz grfico que pone obtener hora del servidor. El fichero javascript sera 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 sera el siguiente: <?php abstract class HoraremotaApplication EyeosApplicationExecutable { public static function obtenerHora() { return date('l jS \of F Y h:i:s A'); } } ?> extends

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 bsica explicada en el captulo anterior. En el fichero javascaript se ha programado el interfaz de usuario, y en el fichero php se ha definido la nica funcin del PHP de la aplicacin que se ejecutar desde el javascript, usando callMessage. El cdigo de la aplicacin en javascript est programado usando una librera grfica de javascript llamada qooxdoo. Qooxdoo permite desarrollar interfaces grficas 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 dems elementos que se insertan en la ventana. En el siguiente captulo se trata a fondo qooxdoo y como funciona.

26

9. Qooxdoo
Tal como hemos visto en el captulo anterior, qooxdoo es una librera grfica para crear interfaces de usuario similar a como se hara en una aplicacin de escritorio utilizando libreras como Qt, Gtk o Swing. Normalmente, las aplicaciones web se desarrollan usando XHTML, css y tecnologas similares, sin embargo, el enfoque de qooxdoo es que el desarrollador desarrolle una interfaz similar a como sera 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 estn desarrolladas utilizando esta librera grfica. Es imprescindible leer el tutorial de qooxdoo para poder desarrollar y entender las libreras. Podramos entonces resumir el desarrollo de una aplicacin a crear el interfaz grfico en javascript usando qooxdoo y llamar a las funciones del fichero php de la aplicacin 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 aplicacin. 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 librera grfica, el desarrollador ya tiene todas las clases de qooxdoo cargadas en el navegador cuando se ejecuta su aplicacin, 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 captulo anterior, donde se crea una ventana con un botn y una caja de texto, se agrega un listener al botn, para 27

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 botn, 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 algn sitio, segn 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 mtodo open, se inserta automticamente 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 debera preocuparse de ningn 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. Mdulos de apliacin (execmodules)

Hemos visto que se pueden agregar funciones en el php de la apliacin, en forma de mtodos publicos estticos, que son llamados desde javascript mediante callMessage. Sin embargo, existen una serie de mtodo que toda aplicacin debera tener, por ejemplo, una funcin close en el php que se ejecute al cerrar la aplicacin, que sera muy pesado tener que ir rehaciendo cada vez que hacemos una aplicacin nueva. Es por eso que en realidad las aplicaciones ya disponen de algunos mtodos en el PHP heredados de la clase padre EyeosApplicationExecutable, que pueden ser llamados desde el javascript usando callMessage, igual que cualquier mtodo definido por nosotros. Esto a la prctica signfica 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 aplicacin. Ests funciones que vienen por defecto, estn en eyeos/system/Frameworks/Applications/Executables/EyeosModu les/, Por ejemplo, si abrimos: eyeos/system/Frameworks/Applications/Executables/EyeosModul es/ContactsExecModule.php, dentro encontraremos una serie de funciones, que estarn disponibles en nuestra aplicacin, para ser ejecutadas mediante callMessage. Por ejemplo: public static function getAllContacts($params) { Si quisieramos ejecutarla desde el javascript, sera mediante: eyeos.callMessage(checknum, params, function()); __Contacts_getAllContacts,

Es igual que un callMessage normal ,pero en el nombre de la funcin PHP a ejecutar, le ponemos delante __Contacts_ ya que en este caso, la funcin estaba en el fichero ContactsExecModule. Muchas aplicaciones utilizan estas funciones para no tener que ir siempre declarando las mismas funciones genricas, como por ejemplo una funcin 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 interacten con el servicio de usuarios de eyeOS. Algunas de sus funciones incluyen la creacin de nuevos usuarios en el sistema, el listado de todos los usuarios, la eliminacin 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 accin, por ejemplo, un usuario que no sea administrador no podr crear nuevos usuarios ni eliminar existentes a travs 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 excepcin, que provocar que el $exists = true no se llegue a ejecutar nunca. Debajo de ese bloque, podemos comprobar si $exists es true o false. Tambin 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 sesin y no a la sesin de otro usuario. Proc Manager dispone de un mtodo para obtener el proceso actual (current process), de forma que una aplicacin puede pedir su propio proceso, para manipularlo, por ejemplo, cerrarse a si misma. Los privilegios del usuario, estn 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 aplicacin 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 mnimos. Una aplicacin 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 informacin del proceso en ejecucin, por ejemplo, podramos obtener el nombre del primer proceso mediante $procName = $processes[0]->getName();

31

13. File System Interface

A la hora de desarrollar una aplicacin, existen diferentes maneras de acceder a ficheros por ejemplo a travs 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 documentacin oficial de la funcin 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 abstraccin, 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 supervisin de un servicio de seguridad, otra capa de abstraccin que veremos mas adelante, capaz de gestionar los permisos de los ficheros y elegir si permitir o no permitir una operacin en concreto. El FSI proporciona al desarrollador una API, capaz de abstraer el desarrollador de los problema de seguridad y consistencia, adems 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 estn fsicamente en el disco duro del servidor, en un servidor ftp, en un punto de montaje de otro dispositivo, en una carpeta compartida a travs de diferentes protocolos, etc. Unas de las principales funciones del FSI es getFile, que toma una ruta como parmetro y devuelve, despus 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 dueo de este fichero pero si que tenga permisos para leerlo, etc. Si el fichero existe y si los permisos estn bien, la funcin getFile devuelve un EyeFile Object, sobre el que el desarrollador puede trabajar de manera fcil 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 conclusin el FSI es unos de los servicios mas importante de eyeOS, y los desarrolladores deberan acceder siempre los ficheros a travs 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 informacin del sistema, as como acceso a recursos, comprueban los privilegios del usuario que ha ejecutado el proceso, antes de realizar ninguna operacin. Los privilegios se comprueban contra una serie de reglas, estilo ACL, que determinan si finalmente el usuario puede o no puede realizar esa accin. 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 inters, 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, estn 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 travs 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 parmetro 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 (ntese 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 continuacin:
<handler flag="sufficient" /> class="ShareableObjectSecurityHandler"

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 bsico 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 seguirn 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 configuracin.

35

15. Metadatos
En muchas ocasiones se necesita asociar informacin a un objeto, para cuando mas adelante el objeto se recupere, poder volver a recuperar esa informacin. 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 informacin 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 prxima vez que vuelva a tener esta instancia, puede recuperar esa informacin. Esto se usa internamente en el propio eyeOS para los permisos de los ficheros, para los datos personales de un usuario, etc. Un ejemplo bsico 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 = >retrieveMeta($user); MetaManager::getInstance()-

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. Conversin de documentos de oficina

La API de conversin de documentos de oficina permite al desarrollador convertir documentos de oficina entre distintos formatos de forma fcil. 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 ningn plugin. Uno de los pasos del manual de instalacin de eyeOS es instalar un OpenOffice en el servidor y ejecutarlo en forma de servidor. La API de conversin de documentos se conecta a este OpenOffice y le pide conversiones de documentos. El conversor de documentos de oficina solo necesita dos parmetros. 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 = (StarWriter)'); $myConverter->Convert($filepath, 'HTML

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 conversin. 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 conversin depende de la velocidad de procesado del servidor.

37

17. Dbus
Dbus es una tecnologa disponible en el lado javascript de las aplicaciones, proporciona un canal de comunicacin comn a todas las aplicaciones, donde cualquier aplicacin puede enviar un mensaje y cualquier aplicacin leerlo. Su principal misin es la comunicacin de las aplicaciones entre si en el javascript. Por ejemplo, cuando el uploader de ficheros termina de subir un fichero a un directorio, enva un mensaje por el dbus informando que ha creado ese fichero ah, por si hay algn gestor de ficheros abierto en ese directorio, que actualice y muestre el fichero nuevo. Esta tecnologa se utiliza para muchsimas 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 envas, 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 enva el mensaje uploadFinished, con el type upload. De esta forma, solo lo recibirn quienes tengan un listener haca 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 documentacin de los mensajes a dbus y su type que envan las aplicaciones base de eyeOS.

38

18. NetSync, tiempo real

Debido a que eyeOS puede ser usado en el mismo servidor simultneamente 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 efecta una accin, otros usuarios pueden ser notificados en tiempo real, es decir, sin necesidad de que hagan click en actualizar. Http es un protocolo de conexin 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 peticin. El problema es que si un usuario se conecta y hace una peticin, que afecta a un tercer usuario, este tercer usuario no podr ser notificado (visualmente, por ejemplo) hasta que no realice otra peticin, lo que normalmente suele ser, hasta que no refresque la pgina. Algunas pginas web han desarrollado un mecanismo mediante el cual una peticin ajax se ejecuta de forma constante cada cierto tiempo, pidiendo si hay notificaciones pendientes. El problema de este mtodo (conocido como http polling) es que consume muchos recursos en el servidor con peticiones intiles, 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 peridicamente a este Proxy, pidiendo al ActiveMQ si hay mensajes, se simula una conexin persistente al ActiveMQ a travs de dicho Proxy, mediante una peticin http que nunca termina, y por la cual vamos recibiendo los mensajes. Utilizando esta tecnologa 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 enva mediante NetSync. El objeto message contiene dentro la informacin 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. Conexin a base de datos

eyeOS internamente funciona por defecto con el motor de base de datos MySQL, aunque utiliza una capa de abstraccin que le permite funcionar con cualquier motor de base de datos SQL estndar. Si una aplicacin necesita tambin conectarse a la base de datos, para crear sus propias tablas y almacenar informacin en ellas, tiene dos formas de hacerlo. La primera, es mediante una conexin normal a la base de datos, eyeOS proporciona una serie de mtodos para obtener una conexin 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 sera: 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 mtodo 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 mtodo 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 mtodo 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 mtodo read. Si suponemos que el campo primary key es el usuario (username), entonces podramos hacerlo as: $this->dao = StorageManager::getInstance()>getHandler('SQL/EyeosDAO', array('prefix' => 'mail')); $usersTO = new usersTO(); $usersTO->setUsername('john'); $usersTO = $this->dao->read($usersTO);

Y al terminar, tendramos $usersTO rellenado con el resto de atributos obtenidos de la base de datos, en este caso, password. Adems, GenericDAO permite obtener todos los registros de la tabla, en forma de array de transferObjects, mediante el mtodo readAll. $this->dao = StorageManager::getInstance()>getHandler('SQL/EyeosDAO', array('prefix' => 'mail')); $usersTO = new usersTO(); $allUsers = $this->dao->readAll($usersTO); En $allUsers tendremos un array de transferObjects, todos rellenados con la informacin de cada usuario de nuestra tabla ficticia usuarios. Para borrar un usuario de nuestra tabla, sera igual que para leerlo, rellenando solo el id, en este caso username, pero llamando al mtodo delete, en lugar de read. Para actualizar la informacin de un usuario, solo habra que hacer un read, cambiar algo, por ejemplo la password, y llamar al mtodo update, pasando nuestro transferObject modificado. La misin del GenericDAO es ocultar el SQL al desarrollador, que solo se preocupa de la lgica de negocio.

43

19.2. Conexin directa

Para realizar sentencias SQL directamente en la base de datos sin utilizar transferObjects, se utiliza tambin el GenricDAO, mediante el mtodo 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 = StorageManager::getInstance()>getHandler('SQL/EyeosDAO', array('prefix' => 'mail')); $this->dao->send(SQL HERE); De esta forma, cualquier aplicacin puede ejecutar SQL directamente en la base de datos. Utilizando el mtodo send del GenericDAO se trabajara igual que usando msyql_query nativo de PHP por ejemplo, solo que es el GenericDAO quien tiene los parmetros de conexin a la base de datos, y quien realiza el mysql_connect.

44

20. Referencias y lecturas recomendadas

Para empezar a desarrollar una aplicacin, 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 informacin. Debido al estado en constante crecimiento de eyeOS 2, es posible que tengas que mirar el cdigo 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 cdigo cuando tengas dudas muy muy profundas. No se debe entender eyeOS como una caja negra cerrada, sino como un conjunto de libereras, que puedes ver su codigo y entenderlas, mejorarlas, extenderlas etc. Para poder desarrollar una aplicacin con xito, es imprescindible adems 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 estn hechas muchas de las aplicaciones que eyeOS tiene. Se puede empezar por calculator o login, que son las mas sencillas.

45