Lo que estoy implementando
Alvaro Durán Tovar
Creo que ya has visto los mensajes de los commits que hice el fin de semana, sobre la implementación del soporte de
idiomas (si has escrito el comentario en googlecode porque también los has empezado tu avisa xD).
Lo que estoy haciendo es que las ventanas lean del fichero "files/language.xml" lo que deben poner. Ese fichero es así:
<languages selected="lang2">
<lang1>
...
</lang1>
<lang2>
...
</lang2>
</languages>
De forma que lo que ponga en "selected" es el nombre de la etiqueta completa del idioma. Así para acceder a un texto
hay que:
1) Leer el atributo selected
2) Acceder al texto buscado usando el atributo del apartado anterior:
xml.getTag("/languages/"+selected+"/lo_que_sea_que_busco");
Creo que de esta forma se hace muy muy fácil cambiar el idioma de forma dinámica (lo estoy haciendo de esa forma).
¿Cómo lo ves?
Por otra parte he estado modificando y optimizando la administración de plugins, además he modificado el sistema de
descargas, creando una pestaña nueva en la ventana de administrar plugins. Así no se llena todo de ventanitas, todas
se descargan en paralelo. (Adjunto foto).
También se me ha ocurrido modificar el administrado de plugins instalados creando un jtree que permita drag and drop.
Si quiero mover un plugin de un módulo a otro sencillamente lo arrastro a la rama que quiera. Si quiero copiarlo
pulso "ctrl" (por decir algo) y lo arrastro. Si quiero eliminarlo pincho encima del plugin y pulso suprimir. ¿Qué
tal así, muy rebuscado? Es que así veo que se le sacaría más partido a los módulos.
Otra cosa que se me ha venido a la cabeza hace un rato es agregar una descripción del plugin en el fichero
"plugin_configuration.xml". De esta forma cuando seleccionas el plugin dentro del árbol de plugins se mostrará una
descripción al lado, leyendo el fichero ese.
¿Crees que merece la pena esto y lo del drag&drop? (Por cierto rejodido lo del DnD con el jtree, dios bendiga el
copy paste xD).
Saludos!!
Pablo Costesich
>
> Hey!
>
> Creo que ya has visto los mensajes de los commits que hice el fin de semana, sobre la implementación del soporte de
> idiomas (si has escrito el comentario en googlecode porque también los has empezado tu avisa xD).
>
> Lo que estoy haciendo es que las ventanas lean del fichero "files/language.xml" lo que deben poner. Ese fichero es así:
>
> <languages selected="lang2">
> <lang1>
> ...
> </lang1>
> <lang2>
> ...
> </lang2>
> </languages>
>
> De forma que lo que ponga en "selected" es el nombre de la etiqueta completa del idioma. Así para acceder a un texto
> hay que:
>
> 1) Leer el atributo selected
> 2) Acceder al texto buscado usando el atributo del apartado anterior:
>
> xml.getTag("/languages/"+selected+"/lo_que_sea_que_busco");
Perfecto, sólo agregaría que los nodos hijos sean las cadenas de
texto. Tendrían un atributo id, otro texto y por último uno opcional
que diga el encoding. Creo que con eso basta. El sistema de búsqueda
es simple, me gusta... Tal vez haría un wrapper en torno a getTag()
para que admita como parámetros el lenguaje y el id.
>
> Creo que de esta forma se hace muy muy fácil cambiar el idioma de forma dinámica (lo estoy haciendo de esa forma).
> ¿Cómo lo ves?
>
Sólo haría el cambio anterior. Ahora miro cómo lo estás implementando,
porque está bastante bueno. ¿Te parece que empiece a reescribir el
tema de XML para agregarlo a librolgps o sigo con el tema de bases de
datos? Yo seguiría con las db's.
> Por otra parte he estado modificando y optimizando la administración de plugins, además he modificado el sistema de
> descargas, creando una pestaña nueva en la ventana de administrar plugins. Así no se llena todo de ventanitas, todas
> se descargan en paralelo. (Adjunto foto).
>
Me gusta más, es más ordenado. ¡Muy bien! :D
> También se me ha ocurrido modificar el administrado de plugins instalados creando un jtree que permita drag and drop.
> Si quiero mover un plugin de un módulo a otro sencillamente lo arrastro a la rama que quiera. Si quiero copiarlo
> pulso "ctrl" (por decir algo) y lo arrastro. Si quiero eliminarlo pincho encima del plugin y pulso suprimir. ¿Qué
> tal así, muy rebuscado? Es que así veo que se le sacaría más partido a los módulos.
>
> Otra cosa que se me ha venido a la cabeza hace un rato es agregar una descripción del plugin en el fichero
> "plugin_configuration.xml". De esta forma cuando seleccionas el plugin dentro del árbol de plugins se mostrará una
> descripción al lado, leyendo el fichero ese.
>
> ¿Crees que merece la pena esto y lo del drag&drop? (Por cierto rejodido lo del DnD con el jtree, dios bendiga el
> copy paste xD).
>
> Saludos!!
>
Mi consejo es que no consumas recursos en cosas que sean tan jodidas.
Es preferible que te centres en la simplicidad... Tu solución es
perfecta (y estándar, por lo que tiene poca curva de aprendizaje).
Te informo que estoy modificando librolgps... Bah, lo estoy separando
en libedb y libexml para bajar el tamaño y complejidad. Es una
librería "grande" y muy desordenada, de la cual dependería el IPC para
mantener los datos en memoria (usaría tablas para mantener
persistencia en los mensajes). Además, quiero almacenar más tipos de
datos y recuperar "blobs" para guardar imágenes. Con eso nos ahorramos
tener librolgps por cada plugin.
Por otra parte, creo que encontré la forma de no depender de importar
las librerías todo el tiempo: hacer que rolgps guarde en lib las que
los plugins necesitan, y cargar el directorio como parte del
classpath. En teoría debería funcionar, aunque no lo probé por
problemas de tiempo (maldito vim, tengo que aprenderlo de memoria
>.<).
Alvaro Durán Tovar
> Perfecto, sólo agregaría que los nodos hijos sean las cadenas de
> texto. Tendrían un atributo id, otro texto y por último uno opcional
> que diga el encoding. Creo que con eso basta. El sistema de búsqueda
> es simple, me gusta... Tal vez haría un wrapper en torno a getTag()
> para que admita como parámetros el lenguaje y el id.
No lo he entendido xD. Si pones un ejemplo mejor. Ya está subido al svn la implementación (y rolgps-v1.0.3
descargable en googlecode, aunque no está puesta la etiqueta para verlo como actualización), por si le quieres echar
un vistazo de como está ahora (incluido el fichero de lenguaje, "files/laguage.xml").
> Sólo haría el cambio anterior. Ahora miro cómo lo estás implementando,
> porque está bastante bueno. ¿Te parece que empiece a reescribir el
> tema de XML para agregarlo a librolgps o sigo con el tema de bases de
> datos? Yo seguiría con las db's.
Me parece bien con peros. librolgps depende de la librería de sqlite no? Y no ocupa poco :S. Si puedes hacer que no
la requiera, o tal vez una versión "lite"? Aunque ya sería empezar a desmenuzar.
> Me gusta más, es más ordenado. ¡Muy bien! :D
Gracias ^^
> Mi consejo es que no consumas recursos en cosas que sean tan jodidas.
> Es preferible que te centres en la simplicidad... Tu solución es
> perfecta (y estándar, por lo que tiene poca curva de aprendizaje).
Encontré un buen ejemplo en la web de como hacerlo sin muchos cambios, así que lo pondré, creo que merecerá la pena.
> Te informo que estoy modificando librolgps... Bah, lo estoy separando
> en libedb y libexml para bajar el tamaño y complejidad. Es una
> librería "grande" y muy desordenada, de la cual dependería el IPC para
> mantener los datos en memoria (usaría tablas para mantener
> persistencia en los mensajes). Además, quiero almacenar más tipos de
> datos y recuperar "blobs" para guardar imágenes. Con eso nos ahorramos
> tener librolgps por cada plugin.
Si puedes separarlo para que no dependa de la librería de sqlite perfecto. ¿Es posible agregar las librerías de xml
(la de xpath y la de JDOM) dentro de "libexml", en el mismo jar, dentro? Lo digo para hacerlo más fácilmente
portable.
> Por otra parte, creo que encontré la forma de no depender de importar
> las librerías todo el tiempo: hacer que rolgps guarde en lib las que
> los plugins necesitan, y cargar el directorio como parte del
> classpath. En teoría debería funcionar, aunque no lo probé por
> problemas de tiempo (maldito vim, tengo que aprenderlo de memoria
> >.<).
Creo que no funcionaría, aunque podría ser una buena solución. Al cargar el .jar (con el jarclassloader) se hace lo
siguiente (a mí me costó entenderlo xD):
Se crea una url espcial apuntando al fichero .jar que se quiere acceder mediante la JVM.
Ese objeto url se usa para crear un objeto URLClassLoader (creo que se llamaba así), que sirve para cargar una clase
desde una url.
Con ese objeto, que apunta a un jar. puedes ejecutar .forName() (si no recuerdo mal) y te devuelve un objeto de tipo
Class. Ese objeto de tipo class ya es perfectamente usable, en ese momento ya tiene sus librerías cargadas en
memoria, sin necesidad de indicárselo, ¿cómo? Porque la JVM ha carga las librerías indicadas en el fichero MANIFIEST
(fíjate que ese fichero indica dependencias también xD, yo no lo sabía).
Entonces a menos que modifiques el MANIFIEST no podrás usar esa solución que has pensado (no directamente), porque al
tratar de cargar la clase en la JVM dirá que le faltan las librerías indicadas como dependencias. Nose si se
entendió.
Tal vez lo que se podría hacer es que ANTES de cargar .jar del plugin cargar sus librerías (lo que agrega la
complejidad de comprobar que librerías necesita) (SIN modificar el MANIFIEST) o bien cargar al inicio de rolgps todas
las librerías que tenga. De esa forma tal vez (cargando todo al inicio) se pueda conseguir tener una sola copia de
cada librería en el disco.
PD: ¿Has visto que ya se pueden registrar alumnos en el google summer of code? ¿Sabes algo de ella, de gente que
haya participado? ¿Se podría intentar buscar patrocinador de rolgps ahí? quien sabe xD.
Pablo Costesich
>
>
>> Perfecto, sólo agregaría que los nodos hijos sean las cadenas de
>> texto. Tendrían un atributo id, otro texto y por último uno opcional
>> que diga el encoding. Creo que con eso basta. El sistema de búsqueda
>> es simple, me gusta... Tal vez haría un wrapper en torno a getTag()
>> para que admita como parámetros el lenguaje y el id.
>
> No lo he entendido xD. Si pones un ejemplo mejor. Ya está subido al svn la implementación (y rolgps-v1.0.3
> descargable en googlecode, aunque no está puesta la etiqueta para verlo como actualización), por si le quieres echar
> un vistazo de como está ahora (incluido el fichero de lenguaje, "files/laguage.xml").
>
Un ejemplo:
<languages>
<language name="Spanish">
<string id=1 encoding="UTF-8">
"asd"
</string>
</language>
</languages>
¿Se puede hacer algo como eso? Tengo dudas sobre lo del tag string.
> Me parece bien con peros. librolgps depende de la librería de sqlite no? Y no ocupa poco :S. Si puedes hacer que no
> la requiera, o tal vez una versión "lite"? Aunque ya sería empezar a desmenuzar.
>
Es que la librería en C pesa poco, pero ahí hay tres o cuatro, más una
en una máquina virtual (en arquitectura MIPS) y el wrapper de java.
Por eso te decía lo del classpath, porque en teoría funciona. La idea
sería tener un sólo jar por cada implementación y no por plugin. Ahora
estoy escribiendo libedb, que es más chico que librolgps... Pero...
Depende siempre de sqlite, derby o de mysql (realmente no es difícil
implementarlos). Es por eso que planeaba usarlos en libGatekeeper (el
servidor del IPC), así teníamos una sola base de datos y todos se
comunicaban a través de esa micro-implementación del IPC.
> Gracias ^^
>
¡De nada! :D
> Encontré un buen ejemplo en la web de como hacerlo sin muchos cambios, así que lo pondré, creo que merecerá la pena.
>
Entonces perfecto. :D
>
> Si puedes separarlo para que no dependa de la librería de sqlite perfecto. ¿Es posible agregar las librerías de xml
> (la de xpath y la de JDOM) dentro de "libexml", en el mismo jar, dentro? Lo digo para hacerlo más fácilmente
> portable.
>
Lo que pasa es que sqlite es la que se encarga del bajo nivel de
archivo y traducción de SQL a archivo. Podría hacer un motor no
relacional de texto o conseguir uno similar, pero por eso es que
quiero implementar Derby para una versión lite. Podría implementar un
JNI, pero ahí perdemos toda la portabilidad.
> Tal vez lo que se podría hacer es que ANTES de cargar .jar del plugin cargar sus librerías (lo que agrega la
> complejidad de comprobar que librerías necesita) (SIN modificar el MANIFIEST) o bien cargar al inicio de rolgps todas
> las librerías que tenga. De esa forma tal vez (cargando todo al inicio) se pueda conseguir tener una sola copia de
> cada librería en el disco.
>
Es más parecida a la segunda. En realidad, al encontrar sólo esa
librería entonces cargaría la misma, según lo que tengo entendido. Es
cierto, se puede producir la carga entre dos ClassLoaders distintos,
pero debería poder eliminarse esa ambigüedad al no encontrar otro jar
en otro path. Creo, hay que hacer la prueba. :S
> PD: ¿Has visto que ya se pueden registrar alumnos en el google summer of code? ¿Sabes algo de ella, de gente que
> haya participado? ¿Se podría intentar buscar patrocinador de rolgps ahí? quien sabe xD.
>
Mañana pregunto a un conocido xD
Alvaro Durán Tovar
> Un ejemplo:
>
> <languages>
> <language name="Spanish">
> <string id=1 encoding="UTF-8">
> "asd"
> </string>
> </language>
> </languages>
¿Pero para qué sería útil el encoding? Quiero decir que solo se usa realmente al abrir el fichero, leyendo la
cabecera (y esto lo hace la librería). ¿De qué forma usar el encoding dentro de rolgps? Es que no veo para que
usarlo.
> ¿Se puede hacer algo como eso? Tengo dudas sobre lo del tag string.
Perfectamente se puede hacer xD. Lo que hago para usar archivos xml es mediante expresiones XPath. No se exáctamente
como pensarías en hacer la selección, pero mediante xpath se puede elegir tanto un grupo de etiquetas, como una
etiqueta concreta, una etiqueta con un valor en un atributo concreto, un atributo... cualquier cosa.
> Es que la librería en C pesa poco, pero ahí hay tres o cuatro, más una
> en una máquina virtual (en arquitectura MIPS) y el wrapper de java.
> Por eso te decía lo del classpath, porque en teoría funciona. La idea
> sería tener un sólo jar por cada implementación y no por plugin. Ahora
> estoy escribiendo libedb, que es más chico que librolgps... Pero...
> Depende siempre de sqlite, derby o de mysql (realmente no es difícil
> implementarlos). Es por eso que planeaba usarlos en libGatekeeper (el
> servidor del IPC), así teníamos una sola base de datos y todos se
> comunicaban a través de esa micro-implementación del IPC.
¿Cuando explicas lo del IPC detalladamente? :P, no se que es un IPC :S
> Es más parecida a la segunda. En realidad, al encontrar sólo esa
> librería entonces cargaría la misma, según lo que tengo entendido. Es
> cierto, se puede producir la carga entre dos ClassLoaders distintos,
> pero debería poder eliminarse esa ambigüedad al no encontrar otro jar
> en otro path. Creo, hay que hacer la prueba. :S
Ahora que he terminado lo de la administración miraré esto del classpath y lo de las nuevas librerías que estás
haciendo :D