85meneos
Como utilizar OpenOffice desde PHP
www.nativos2020.com/2008/02/23/como-utilizar-openoffice-desd... por jcarlosn el 23-02-2008 19:17 UTC
Explicación de como utilizar OpenOffice instalado en el servidor web, desde PHP, y así poder convertir documentos de oficina a formatos visualizables por el navegador, o al formato que queramos, es una forma de salvar el obstáculo de los formatos cerrados, poco documentados, o a los que PHP no da soporte. Se dan un par de ejemplos, como pasar de ods a xhtml, y extraer una presentación en forma de imágenes JPEG.
menéame
Crear un código PHP para comunicarse con UNO en pure-php es un proyecto de una envergadura MUY considerable, yo considero que técnicamente es cierto que usar UDK sería lo mas parecido a COM, pero en cuestiones de facilidad, quien está acostumbrado a COM de Office, esto lo mas cercano, no tiene pies ni cabeza que para hacer una web, tengas que implementarte bindings en C++, aparte de la perdida de portabilidad que ello conlleva.
Cuando te digo portabilidad, es que meter una macro en el OOo y ejecutarla con shell_exec, se puede hacer en 1 minuto, por cualquiera, y en cualquier sistema operativo (¿estás insinuando que shell_exec es solo para un sistema concreto, por ejemplo, Unix? ;-) )
Sin embargo, un binding a PHP, tal como describes, no es un proceso tan sencillo, yo puedo resumir en 3 pasos el uso con macros:
1. instala OOo
2. copia la macro al directorio Tools
3. ejecútala
Todos los sistemas operativos disponen de llamadas al sistema para ejecutar OOo con parametros, en todos los sistemas operativos en los que se soporta OOo, se soporta el uso de parametros.
Entonces, me estás diciendo que mi explicación es poco congruente, solo por que yo hago un matiz para Unix, donde existe un problema concreto, (las X) y lo soluciono con Xvfb, cuando toda la explicación es totalmente compatible con cualquier sistema?
Si la gente usa COM en Office de microsoft, es por lo haces en 1 minuto, y la solución análoga que tu planteas es:
1. desarrollar un código en C++
2. hacer un binding con swig
3. iniciar el servicio UNO en OOo (startserver)
4. conectar con el usando el binding
Eso, a mi modo de verlo, es matar moscas a cañonazos.
También podríamos crear un sistema operativo que no cargase nada excepto el PHP, el binding, y lo que necesite el OOo y echo para el hardware de nuestro servidor, ya verías que rápido iría, pero obviamente, no tiene sentido.
A lo que me vengo a referir, es que las soluciones desproporcionadas a problemas cotidianos, no son siempre la mejor idea, tenemos el ejemplo de corba vs xml-rpc, y finalmente, xml-rpc está muchísimo mas extendido (con web services) o incluso rmi (remote method invocation), con java, sin embargo, la mejor solución (técnicamente) es corba.
Yo por lo general, cuando hablamos del mundo web, e incluimos el "te haces un binding en c++" ya desecho la propuesta, por que si estás ofreciendo software libre a terceros, vas a tener que dar compilables, con configures etc, solo para instalar una web.
Me reitero, la gente no usa COM por que sea lo mas correcto, sino por que es lo mas sencillo.
Creo que no te he entendido, debo estar un poco lento.
1. instala OOo
2. copia la macro al directorio Tools
3. ejecútala
1. desarrollar un código en C++
2. hacer un binding con swig
3. iniciar el servicio UNO en OOo (startserver)
4. conectar con el usando el binding
Creo que has sido un poco parcial en estas dos listas que has hecho (todos lo somos :-)), porque con tu solución no has contado con que también que hay que desarrollar las macros y que la parte de conectar a OOo ya viene incluida en el binding. Además de que, el código ya está desarrollado, mira el enlace que he puesto. Por cierto, el código de SWIG es tan complicado como escribir esto:
%module ooophp
%{
#include "ooophp.h"
%}
%include "ooophp.h"
Eso, a mi modo de verlo, es matar moscas a cañonazos.
Depende de la soltura que tengas en C o C++, a mí me parece una solución válida para hacer una tarea muy muy muy concreta (por favor, no insinues lo de hacer toda la web en C++), muy delimitada en funcionalidades y que puede proporcionarte mucho beneficios. Además de que ya está hecho :-)
También podríamos crear un sistema operativo que no cargase nada excepto el PHP, el binding, y lo que necesite el OOo y echo para el hardware de nuestro servidor, ya verías que rápido iría, pero obviamente, no tiene sentido.
Ejem, creo que esto sobraba :-) Creo que estarás de acuedo conmigo en que es un poco demagógico.
A lo que me vengo a referir, es que las soluciones desproporcionadas a problemas cotidianos, no son siempre la mejor idea, tenemos el ejemplo de corba vs xml-rpc, y finalmente, xml-rpc está muchísimo mas extendido (con web services) o incluso rmi (remote method invocation), con java, sin embargo, la mejor solución (técnicamente) es corba.
Pues no, CORBA no es la mejor solución siempre, dependerá siempre del caso. Por otra parte, desarrollar un escritorio web y proporcionar herramientas para convertir formatos, no es un problema cotidiano :-)
Me reitero, la gente no usa COM por que sea lo mas correcto, sino por que es lo mas sencillo.
Pero lo que has escrito no es como COM (CORBA sería COM en este caso), puesto que no estás trabajando con los componentes de UNO. En ningún momento he dicho que esté mal lo que has hecho, si a ti te funciona perfecto, pero hay otras formas de hacerlo más limpias.
Un problema que te puede surgir con tu solución es que si sucede algún error, no sabes qué ha pasado y no podrás informar al usuario. Otro será que si nadie está ejecutando OOo, la próxima vez que alguien haga una petición se cargará todo en memoria. También está el problema de que, si lo deseas, no podrás poner OOo en una máquina "gorda" (o varias), y varios servidores front-end haciéndole(s) peticiones, tendrás que instalar y configurar OOo+Xfvb en cada máquina nueva, añadiendo más carga a los administradores.
Bueno, si quieres podemos seguir la conversación por e-mail, o continuarla en menéame :-)
Sin embargo, una puntualización:
También está el problema de que, si lo deseas, no podrás poner OOo en una máquina "gorda" (o varias), y varios servidores front-end haciéndole(s) peticiones, tendrás que instalar y configurar OOo+Xfvb en cada máquina nueva, añadiendo más carga a los administradores.
A no? que me lo impide? no veo el problema aquí, solo tendrías que poner el PHP que hace de front-end en la máquina gorda, y consumirlo desde las máquinas front-end.
No quiero decir que la solución con UNO no sea válida, solo quiero decir, que en muchos casos, no es la mejor, debido a que requiere códigos específicos en C++, que requieren ser compilados en la máquina objetivo, lo cual ya tiene unas implicaciones de por si.
Acerca de mi soltura con el C++, no tengo ningún problema, como ya he dicho, conozco el sdk de OOo.
Por cierto, tu link al código de SergeM no es óptimo, no es compilable tal cual, y el mismo dice que ya dará mas información.
Para un código listo para usar (aunque habría que mejorar algunos aspectos):
www.oooforum.org/forum/viewtopic.phtml?t=27453=
:-)
Eso no, pero lidiar con formatos de archivo, si.
La solución que propones para distribuir la carga de OOo es curiosa, yo no sería partidario puesto que habría que añadir varias capas más que se pueden evitar usando algo más pequeño (y que ya está hecho, es lo más importante). Pero ¡ojo! no digo que sea errónea, sólo que yo no la usaría. Los otros problemas que he comentado, ¿habría alguna manera de gestionarlos con tu solución? A mí no se me ocurre (lo máximo que se me ocurre es comprobar los códigos de retorno), pero si a ti sí, me gustaría leerlas. Si he propuesto lo de PHP+C++ es porque no se me occure la manera de arreglar lo otro con tu solución.
Mi link al código de SergeM incluye un enlace al código correcto (el que tú has puesto), apunté a la discusión original para saber de dónde salía, por si tenías curiosidad.
Por cierto, cuando he hablado de tener soltura con C++, en ningún momento he dudado de tus capacidades. Simplemente es que si cada día tienes que trabajar con este lenguaje y te tienes que pelear con él, al final hasta acabas cogiéndole cariño (no demasiado, eso sí) y no se te hace tan complicado usarlo.
#8 si cambias el tema, las conclusiones no son las mismas (falacia del hombre de paja, que diría alguno). Y fíjate, que he dicho que lo que hacéis no es algo cotidiano, hacéis una gran labor con el eyeOS. ¿Era necesario ponerse a la defensiva?