[Gvsig_desarrolladores] Módulo de scripting - getLayers

Joaquin Jose del Cerro Murciano jjdelcerro en gvsig.org
Mar Dic 9 11:21:25 CET 2014 

El 9 de diciembre de 2014, 10:34, Francisco Puga <fpuga en icarto.es> escribió:

> Gracias por la explicación Joaquín, ahora entiendo mejor el
> funcionamiento del módulo.
>
> Entonces aprovecho este hilo para otra pregunta rápida. ¿Alguna idea
> de como hacer que el encoding en la consola del composer sea correcto?
>
> Un simple:
>
> print u"título"
>
> no me funciona bien, he probado también con .encode("utf-8") y esas
> cosas pero no lo he conseguido, y no encuentro mucha documentación de
> jython al respecto.
>
>

Holas,
pues la verdad es que no se por que sucede.
De encoding no se mucho, mas bien todo lo contrario, se bastante poco.

Es muy probable que el error este en el codigo java que se encarga de
mostrar los
errores en la consola del composer.

Aprovecho y comento lo que hay por si alguien sabe mas que yo y puede
sugerir una solucion que no sea "ir probando a ver si atino".

Lo primero es que no se que codificacion estan usando las cadenas de jython.
Para mostrarlas en la consola del Composer (DefaultJScriptingComposer) se
hace:

- Se crea un PrintStream y se asigna la salida standard y la salida standar
de errores, para
  interceptar todo lo que salga por estas y pasarlo a la consola del
Composer, ya que desde jython
  lo unico que se hace son prints normales que salen por la salida standar
o la de errores si son
  errores.

        System.setOut(this.getConsolePrintStream());
        System.setErr(this.getConsolePrintStream());

- El PrintStream se crea con una especializacion de OutputStream.

            JTextAreaOutputStream outputConsole = new
JTextAreaOutputStream(console);
            this.consolePrintStream = new PrintStream(outputConsole);

- Y la clase JTextAreaOutputStream, nuestro OutputStream, vuelca los datos
al JTextArea
  de la consola del Composer. Este seria su constructor y su metodo write:

        public JTextAreaOutputStream(JTextArea t) {
            super();
            textArea = t;
        }

        public void write(char[] buf, int off, int len) {
            String s = new String(buf, off, len);
            textArea.append(s);
        }

Ni idea de donde hay que indicar el encoding si es que hay que hacerlo en
algun lado.

- Cuando se crea el PrintStream
- En algun sitio que se me escapa del OutputStream del que extiende
JTextAreaOutputStream.
- Cuando en el metodo write se construye el String... deberia construirse
de alguna otra forma e indicar el CharSet que se esta utilizando.
- O es cosa que al hacer el print desde el script se contruya el String de
alguna forma en concreto.

Si alguien sabe mas y me ilumina un poco se agradeceria.

Un saludo
Joaquin








> El día 9 de diciembre de 2014, 9:59, Joaquin Jose del Cerro Murciano
> <jjdelcerro en gvsig.org> escribió:
> >
> >
> > El 8 de diciembre de 2014, 14:12, Francisco Puga <fpuga en icarto.es>
> escribió:
> >>
> >> Hola,
> >>
> >> Estoy haciendo el curso de scripting y me pasa una cosa curiosa. Si
> >> ejecuto este código:
> >>
> >>
> >> for v in project.getViews():
> >>     for l in project.getView(v.name).getLayers():
> >>         print l.name
> >>
> >> todo funciona bien. Pero si ejecuto:
> >>
> >>
> >> for v in project.getViews():
> >>     for l in v.getLayers():
> >>         print l.name
> >>
> >> Parece como si el objeto que devolviera getViews fuera distinto al que
> >> devuelve getView. Estoy usando el build 2252
> >
> >
> > Hola Francisco,
> > Algo de explicacion para un desarrollador java...
> > Actualmente hay dos versiones de las librerias de scripting:
> >
> > - la primera, la que se hizo para gvSIG 2.0.0 y es la que esta en uso
> > actualmente, consiste basicamente en un juego de modulos python que
> recubren
> > parte de las librerias java de gvSIG.
> >
> > - La segunda libreria, que se inicio su desarrollo para la 2.1.0, tiene
> una
> > aproximacion completamente distinta. Lo que hace es extender la
> definicion
> > de clases de java con metodos de utilidad para python, pero sin
> recubrirlos
> > con un API python. Va directamente a las clases de java y le inyecta los
> > nuevos metodos. Se ha intentado mantener el mismo API que con la primera
> > aproximacion y si mal no recuerdo a excepcion de un par de metodos se
> estaba
> > consiguiendo.
> >
> > Cada una de las aproximaciones presenta sus ventajas e inconvenientes.
> > La principal desventaja de la primera es que si accedes a un metodo que
> no
> > esta recubierto por la clase python y este devuelve otro objeto, el nuevo
> > objeto que obtendras es el objeto java, aunque exista una clase python
> para
> > recubrirlo.
> > Por ejemplo, si accedes al metodo "getViews" del proyecto, estas
> accediendo
> > al metodo nativo de java ya que este metodo no esta recubierto por la
> clase
> > Project de python. Con lo que las vistas que obtienes son las de java y
> no
> > las de la clase View de python. Si intentas invocar al metodo getLayers,
> > este solo lo tiene la clase View de python y no la de java, por lo que te
> > falla. La version del bucle que  te funciona, lo hace por que el metodo
> > getView (singular) si que esta recubierto en la clase python, y te
> devuelve
> > el recubrimiento python de la clase View que si que tiene el metodo
> > getLayers.
> >
> > Espero que se entienda este pequeño trabalenguas.
> >
> > La segunda aproximacion de la libreria python soluciona este tipo de
> > problemas ya que solo hay una clase, la de java, a la que desde python
> se le
> > inyectan los metodos de utilidad propios de python, pero presenta el
> > problema que solo se le pueden inyectar metodos, no se le pueden añadir
> > atributos, ademas de requerir un mayor conocimiento de como trabaja el
> motor
> > de jython, que cuando se abordo la primera aproximacion no teniamos.
> > La gran ventaja de esta aproximacion es que obtengas como obtengas un
> objeto
> > java, siempre tendra los metodos que se inyectaron en su clase, y nunca
> te
> > podra pasar algo parecido a lo que te ha sucedido.
> >
> > La implementacion de esto esta muy avanzada, de echo creo que ya podria
> > empezar a testearse, pero como siempre faltan manos en la parte de
> > "conocimiento del API de java de gvSIG" para poder hacerlo.
> >
> > Con las ultimas versiones del plugin de scripting va incluida la nueva
> > version del modulo de python "gvsig" (nombrado como gvsig21, en
> >
> gvSIG/extensiones/org.gvsig.scripting.app.extension/scripting/lib/gvsig21),
> > pero no recuerdo exactamente en que estado se quedo.
> >
> > Un saludo
> > Joaquin
> >
> >
> >>
> >>
> >> AttributeError: 'org.gvsig.app.project.documents.view.DefaultViewDo'
> >> object has no attribute 'getLayers' in <script> at line number 16
> >> org.gvsig.scripting.ExecuteErrorException: AttributeError:
> >> 'org.gvsig.app.project.documents.view.DefaultViewDo' object has no
> attribute
> >> 'getLayers' in <script> at line number 16
> >> at
> >>
> org.gvsig.scripting.impl.DefaultScriptingScript.invokeFunction(DefaultScriptingScript.java:314)
> >> at
> >>
> org.gvsig.scripting.impl.DefaultScriptingScript.run(DefaultScriptingScript.java:301)
> >> at
> >>
> org.gvsig.scripting.impl.DefaultScriptingScript$ScriptTask.run(DefaultScriptingScript.java:372)
> >>
> >> _______________________________________________
> >> gvSIG_desarrolladores mailing list
> >> gvSIG_desarrolladores en listserv.gva.es
> >> Para ver histórico de mensajes, editar sus preferencias de usuario o
> darse
> >> de baja en esta lista, acuda a la siguiente dirección:
> >> http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_desarrolladores
> >>
> >
> >
> >
> > --
> > --------------------------------------
> > Joaquin Jose del Cerro Murciano
> > Development and software arquitecture manager at gvSIG Team
> > jjdelcerro en gvsig.com
> > jjdelcerro en gvsig.org
> > gvSIG Association
> > www.gvsig.com
> > www.gvsig.org
> >
> > _______________________________________________
> > gvSIG_desarrolladores mailing list
> > gvSIG_desarrolladores en listserv.gva.es
> > Para ver histórico de mensajes, editar sus preferencias de usuario o
> darse
> > de baja en esta lista, acuda a la siguiente dirección:
> > http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_desarrolladores
> >
>
>
>
> --
> Francisco Puga
> iCarto | Innovación, Cooperación, Cartografía y Territorio S.L.
> http://www.icarto.es/
>
> c/ Rafael Alberti nº 13 – 1º D
> 15008 A Coruña
> Galicia (Spain)
> +34 881927808
>
> Este correo electrónico contiene información estrictamente
> confidencial y es de uso exclusivo del destinatario, quedando
> prohibida a cualquier otra persona su revelación, copia, distribución,
> o el ejercicio de cualquier acción relativa a su contenido. Si ha
> recibido este mensaje por error, por favor conteste a su remitente
> mediante correo electrónico y proceda a borrarlo de su sistema.
>
> Sus datos personales serán tratados de forma confidencial y no serán
> cedidos a terceros ajenos a ICARTO. En cualquier caso, podrá ejercer
> los derecho de oposición, acceso, rectificación y cancelación de
> acuerdo con lo establecido en la Ley Orgánica 15/99, de 13 de
> diciembre, de Protección de Datos de Carácter Personal dirigiéndose a
> Innovación, Cooperación, Cartografía e Territorio, SL. (ICARTO) en la
> dirección postal a C/ Rafael Alberti, nº 13, 1ºD, 15.008 – (A Coruña).
> _______________________________________________
> gvSIG_desarrolladores mailing list
> gvSIG_desarrolladores en listserv.gva.es
> Para ver histórico de mensajes, editar sus preferencias de usuario o darse
> de baja en esta lista, acuda a la siguiente dirección:
> http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_desarrolladores
>



-- 
--------------------------------------
Joaquin Jose del Cerro Murciano
Development and software arquitecture manager at gvSIG Team
jjdelcerro en gvsig.com
jjdelcerro en gvsig.org
gvSIG Association
www.gvsig.com
www.gvsig.org
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: http://listserv.gva.es/pipermail/gvsig_desarrolladores/attachments/20141209/9eb4eb9d/attachment.htm

Más información sobre la lista de distribución gvSIG_desarrolladores