Ir al contenido principal

Gráficas como controles en Webforms (2)

Como comentaba en un post anterior, en la versión Rocha se incluye la posibilidad de definir gráficas en un Webform utilizando un "user control" que viene "built-in" con la versión.

En los sucesivos builds se ha ido mejorando esta funcionalidad y se ha incluído un "breaking change" (por suerte muy sencillo de adaptar el código) que es el cambio en la definición de los "data types" asociados al Chart.



Como se mencionaba en ese post, en builds anteriores se definía un "data type" para las categorías  y otro para las series. A partir de build 10.0.0.5911 (de Rocha CTP4) se define un solo tipo de datos GXchart lo que hace mucho más "intuitivo" el uso del mismo:
gxchart1.jpg
 De este modo ahora, en los objetos que usen el control, se define una variable para las categorías del tipo GXchart y otra/s para la/s serie/s del tipo GXchart.Serie.

Subí una nueva versión a GXopen.com reflejando estos cambios, solo tuve que cambiar los tipos de datos de las variables que utilizaba.

Creo que hay dos "paradigmas" de uso de un Chart: resolviendo la carga en el mismo que contiene el control y por otro lado resolviendo la carga en otro objeto (un proc por ahora, ¿un miniproc en el futuro?).

Además de eso se han incluído otras funcionalidades, entre ellas la propiedad "ServiceUrl" que permite establecer al URL donde está instalado el servidor de gráficas (por default es www.gxchart.com/service), de este modo se puede bajar el GXchart, instalarlo local y utilizar los servicios del mismo.

Comentarios

  1. [...] Si bien el concepto permanece, se cambió el tipo de datos para hacer más sencillo su uso, por lo cual recomiendo, una vez leido este, leer los cambios que se produjeron. [...]

    ResponderBorrar

Publicar un comentario

Entradas más populares de este blog

Abrir links con aplicaciones nativas y no el browser (deeplinking)

El problema que tengo con algunas aplicaciones Android/iOS es que cuando recibo un link por algún medio (mail, tweet, etc) al abrirlo me lo abre con el browser, en lugar de abrirlo con una aplicación nativa asociada a ese “contenido”. Por ejemplo, si recibo un link a un tweet espero que lo abra con alguna aplicación de twitter que tenga instalada y no con el browser. De modo análogo si recibo un mail con una nota de prensa de un medio X y tengo la aplicación de ese medio X instalada, espero que el link lo abra con la aplicación nativa y no con el browser. Lo mismo quisiera con mi aplicación de "banking" o cualquiera que tenga instalada y sepa manejar ese "contenido" (link). Los motivos son bastante obvios pero los resumo en: la experiencia de usuario es mucho mejor en la aplicación nativa que en el navegador. Parte importante del tema es que el mismo link sea válido tanto para ver el contenido en el browser como para verlo en la aplicación, porque como prove

¡A la salud de mi KB!

Es bueno, especialmente en "bases de conocimiento" (KB) que han pasado por varias versiones de Genexus, chequear su "estado de salud". En este sentido KBDoctor  es una herramienta que ayuda mucho, principalmente desde el punto de vista del "modelo" Genexus (atributos, calls, definiciones de variables, etc) representado en una KB. También es útil revisar la salud de los archivos que lo soportan. Hasta la 9.0 eran archivos C-tree (los famosos .DAT) que tenían indices (los famosos .IDX) y teníamos en "rebuild -y" que mejoraba esos archivos y sobre todo reconstruía los indices. A partir de la X las KBs se almacenan en MS SQL Server por lo cual la administración de la misma pasó de ser un "file server" a un "database server". En este sentido algo que me ha dado muy buenos resultados es el "CheckKnowledgeBase".

Rocha:Constantes tipo fecha

En la Rocha se soportan constantes del tipo fecha o fecha-hora con formato ANSI/ISO (AAAA-MM-DD HH:MM:SS).  Tecnicamente (Sintáxis): <date>::=    [0-9]{1,4}"/"[0-9]{1,2}"/"[0-9]{1,2} | [0-9]{1,4}"."[0-9]{1,2}"."[0-9]{1,2} | [0-9]{1,4}"-"[0-9]{1,2}"-"[0-9]{1,2} <hms>::=    [0-9]{1,2}[ap] | [0-9]{1,2}":"[0-9]{1,2}[ap]? | [0-9]{1,2}":"[0-9]{1,2}":"[0-9]{1,2}[ap]? <constant> ::=   "#"<date>"#" | "#"<date> <hms>"#" | "#"<hms>"#" Funcionalmente Se pueden utilizar esas constantes en las reglas, eventos, propiedades, etc (todo lugar donde se utilice el parser): Algunos ejemplos básicos: &FechaInicial=#2007-01-01# &FechaHoraInicial=#07-1-1 11:15a# &HoraInicial=#11a# Me parece bueno no tener que escribir funciones (CTOD, TTOC) sobre constantes tipo char para lograr una fecha y mucho mejor aun en