A raíz del post anterior sobre webs realizadas con Velneo, en el foro de Velneo surgió la propuesta de un subforo dedicado íntegramente a mostrar webs Velneo.
Para ello se integró snapshots en el código del foro, así se tiene una previsualización del sitio enlazado sin almacenar imágenes del mismo.
Hay una serie de reglas de publicación expuestas en el postit del principio, más que nada por darle un orden y uniformidad a la exposición de una web.
Así que si tienes una web hecha con Velneo, desde aquí te animo a publicarlo en el foro.
Un saludo,
jueves, 31 de enero de 2008
miércoles, 16 de enero de 2008
Modelo de cajas CSS
Lo primero que se debería aprender de CSS, y suele no ser así (yo el primero), es el modelo de cajas que utiliza.
El modelo de la caja del CSS describe las cajas rectangulares que se generan para los elementos en el árbol del documento y se presentan según el modelo visual del formato.
Y esto qué quiere decir?
Cada elemento de html; una capa, un párrafo, una lista, una cabecera, etc..., tiene a su alrededor una caja que lo contiene.
Los elementos componentes de esa caja son
Las partes de cada uno de estos elementos se referencian por su posición respecto del contenido y en este orden: arriba (top), derecha (right), abajo (bottom) e izquierda (left).
Este orden es fácil de aprender; se empieza por arriba y se recorre en sentido horario.
Así un elemento de la caja como por ejemplo el margen tendrá cuatro partes: margin-top, margin-right, margin-bottom y margin-left.
Es bueno recordar esto ya que más adelante veremos cómo nos va a permitir definir las propiedades de cada parte de cada elemento en el CSS.
La dimensión de la caja viene dada por la suma de las dimensiones de todos estos elementos, es decir,
y esto es así.
Otra cosa es lo que IE hace. Y es que el famoso navegador calcula el ancho a su manera sin respetar el estándard.
Así que si vuestra web se ve bien en navegadores que siguen el estándard como Opera, Safari, Firefox, pero no se ve bien en IE: cambiad de navegador.
Es impresionante la cantidad de consultas en foros sobre el tema que aún están enfocadas al revés: "Mi web se ve perfectamente en IE, pero cuál ha sido mi sorpresa al ver que se descuadra en Firefox!"
La respuesta a este tipo de dudas es: "Si haces las cosas bien tu web se verá perfecta en todos los navegadores que siguen el estándard. IE no respeta el estándard así que si los usuarios de IE no ven bien una web tienen dos opciones; quejarse amargamente de ello a Microsoft, o cambiar de navegador"
Es conveniente saber que cada navegador implementa unos valores predeterminados para los diferentes elementos de cada caja, así que si no los definimos en CSS se tomarán esos por defecto.
Otro tema que entronca directamente con el modelo de caja es el árbol del documento.
Html es un lenguaje de etiquetas, y estas etiquetas en cada página están anidadas de cierta forma. Esta anidación de etiquetas conforma una estructura en árbol jerárquica, de forma que constituye lo que se llama el árbol del documento.
En el esquema vemos que una etiqueta puede tener un antecesor, unos descendientes, unos hermanos y compañeros del mismo nivel.
Esto hemos de tenerlo muy en cuenta ya que CSS es un lenguaje de definición de estilos en cascada, es decir las propiedades de los elementos son heredables según el árbol del documento, de forma que si definimos por ejemplo el estilo de letra para el body, todos los elementos descendientes del body heredarán ese estilo.
Si en principio nos quedan claros estos pocos conceptos base sobre cajas, árboles y herencia, ya tendremos mucho avanzado a la hora de entender CSS.
Life is soft!
El modelo de la caja del CSS describe las cajas rectangulares que se generan para los elementos en el árbol del documento y se presentan según el modelo visual del formato.
Y esto qué quiere decir?
Cada elemento de html; una capa, un párrafo, una lista, una cabecera, etc..., tiene a su alrededor una caja que lo contiene.
Los elementos componentes de esa caja son
- El contenido en sí
- El relleno (padding)
- El borde (border)
- El margen (margin)
Las partes de cada uno de estos elementos se referencian por su posición respecto del contenido y en este orden: arriba (top), derecha (right), abajo (bottom) e izquierda (left).
Este orden es fácil de aprender; se empieza por arriba y se recorre en sentido horario.
Así un elemento de la caja como por ejemplo el margen tendrá cuatro partes: margin-top, margin-right, margin-bottom y margin-left.
Es bueno recordar esto ya que más adelante veremos cómo nos va a permitir definir las propiedades de cada parte de cada elemento en el CSS.
La dimensión de la caja viene dada por la suma de las dimensiones de todos estos elementos, es decir,
ancho-caja = margen-izquierdo + borde-izquierdo + relleno-izquierdo + ancho-contenido + relleno-derecho + borde-derecho + margen-derecho
y esto es así.
Otra cosa es lo que IE hace. Y es que el famoso navegador calcula el ancho a su manera sin respetar el estándard.
Así que si vuestra web se ve bien en navegadores que siguen el estándard como Opera, Safari, Firefox, pero no se ve bien en IE: cambiad de navegador.
Es impresionante la cantidad de consultas en foros sobre el tema que aún están enfocadas al revés: "Mi web se ve perfectamente en IE, pero cuál ha sido mi sorpresa al ver que se descuadra en Firefox!"
La respuesta a este tipo de dudas es: "Si haces las cosas bien tu web se verá perfecta en todos los navegadores que siguen el estándard. IE no respeta el estándard así que si los usuarios de IE no ven bien una web tienen dos opciones; quejarse amargamente de ello a Microsoft, o cambiar de navegador"
Es conveniente saber que cada navegador implementa unos valores predeterminados para los diferentes elementos de cada caja, así que si no los definimos en CSS se tomarán esos por defecto.
Otro tema que entronca directamente con el modelo de caja es el árbol del documento.
Html es un lenguaje de etiquetas, y estas etiquetas en cada página están anidadas de cierta forma. Esta anidación de etiquetas conforma una estructura en árbol jerárquica, de forma que constituye lo que se llama el árbol del documento.
En el esquema vemos que una etiqueta puede tener un antecesor, unos descendientes, unos hermanos y compañeros del mismo nivel.
Esto hemos de tenerlo muy en cuenta ya que CSS es un lenguaje de definición de estilos en cascada, es decir las propiedades de los elementos son heredables según el árbol del documento, de forma que si definimos por ejemplo el estilo de letra para el body, todos los elementos descendientes del body heredarán ese estilo.
Si en principio nos quedan claros estos pocos conceptos base sobre cajas, árboles y herencia, ya tendremos mucho avanzado a la hora de entender CSS.
Life is soft!
martes, 15 de enero de 2008
sábado, 12 de enero de 2008
Lego technic
Como es bien sabido por todos los que utilizamos Velneo, es la herramienta de desarrollo de aplicaciones empresariales de gestión más rápida del mercado, y esto nos deja el suficiente tiempo libre como para dedicarlo a nuestros hijos, familia y aficiones diversas.
No sólo de software vive el programador.
Así pues, aprovechando mi tiempo libre he montado esta moto de Lego technic, regalo de reyes.
Una verdadera gozada.
Un saludo,
No sólo de software vive el programador.
Así pues, aprovechando mi tiempo libre he montado esta moto de Lego technic, regalo de reyes.
Una verdadera gozada.
Un saludo,
viernes, 11 de enero de 2008
Diseño web (tablas)
Antiguamente, cuando empecé con el diseño de páginas web, había una escuela de programadores venidos a "diseñadores" web que utilizaban ámpliamente las tablas html para la maquetación visual de los elementos de las páginas; una tabla para centrar la página en el navegador, una tabla para el menú, otra tabla para distribuir los elementos de cada página, etc.
Era una forma fácil de poder hacer que lo que apareciese en los navegadores se asemejara más o menos al diseño gráfico pensado para la web.
Yo también era de esos, planteaba un diseño en Photoshop que luego troceaba y pasaba a Dreamweaver para maquetarlo usando una enorme cantidad de tablas anidadas, lo cual al final ralentizaba la presentación del sitio en los navegadores dada la compleja estructura de tablas anidadas resultantes.
Otro problema subyacente era la accesibilidad. Alguien invidente que utilizase un lector para interpretar esa web fácilmente podía no entender nada de una compleja estructura de tablas que nada tenía que ver con el contenido "real" del sitio web.
Durante un largo periodo de tiempo dedicado a investigar la forma de hacer las cosas en la web me encontré con una escuela de diseñadores web que intentaba separar la forma del contenido, lo cual me interesó mucho por dedicarme básicamente a realizar webs dinámicas donde el contenido está en la base de datos y la forma se encuentra en componentes html que son el front-end para ese medio. Me interesó muchísimo y me puse a estudiarlo.
Así conocí el xhtml + css. Era la nueva web semántica; separación de forma y contenido, la forma se controla mediante css y en el código xhtml no se incluye ninguna etiqueta que tenga que ver con la forma.
Las fuentes y sus tamaños, los colores y fondos, la disposición de elementos, etc, se controla desde css, y el contenido se deja para el código xhtml.
Así las cosas parecía que las tablas eran un elemento a no utilizar en xhtml, pero no es así. Hay elementos claramente tabulares que deben ser mostrados en tablas, que para eso fueron creadas. Así un listado tabulado de información se mostrará utilizando una tabla, un calendario también, y toda aquella información cuya naturaleza sea tabular requerirá de este elemento para ser mostrada.
Las tablas en xhtml no deben ser un tema tabú.
Veamos cómo es una tabla bien formada y accesible.
[table summary="Listado de Repartidores de señal indicando el servicio asociado, las extensiones y pares, así como el elemento D.Hard utilizado"]
[thead]
[tr class="odd"]
[th scope="col" abbr="Repartidor"]Repartidor[/th]
[th scope="col" abbr="Servicio"]Servicio[/th]
[th scope="col" abbr="Extensiones"]Ext.[/th]
[th scope="col" abbr="Pares"]Par[/th]
[th scope="col" abbr="D.Hard"]D.Hard[/th]
[/tr]
[/thead]
[tbody]
[tr]
[td]Ayto. Nuevo - S.S. Yecla[/td]
[td]Jubilados[/td]
[td]2.740[/td]
[td]01[/td]
[td]2.013, 2, 3[/td]
[/tr]
[tr class="odd"]
[td]Parque móvil - Cámaras Becalí[/td]
[td]Bomberos Norte[/td]
[td]4.984[/td]
[td]60[/td]
[td]2.013, 10, 9[/td]
[/tr]
[/tbody]
[/table]
En principio observamos que la tabla tiene un summary que es una descripción de los datos que muestra la tabla. Esto hace que la tabla sea más comprensible.
Debajo del summary podría ir el caption que es el título de la tabla, de forma similar al título de un gráfico de Excel, por ejemplo, para que todos nos entendamos. Este caption también es fácilmente controlable desde css para su aspecto y posición.
Luego pasamos a definir el thead de la tabla que es el grupo de celdas de la tabla que actuarán como cabeceras de columna, como los nombres de columna A, B, C, en una hoja Excel por seguir con la analogía anterior.
En el thead vemos que cada columna cabecera la definimos con th en lugar de td. Esto es así porque esas columnas van a actuar como cabecera de columna y le darán sentido a todos sus td's inferiores.
A continuación del thead podríamos definir de forma similar el tfoot que sería el conjunto de celdas que formarán el pie de la tabla; nota al pie, totalizadores por columna, etc.
Luego viene el tbody, es decir, la "chicha". Aquí es donde van los datos, y se sabe exactamente a qué tipo de dato corresponde cada celda porque lo hemos definido con anterioridad en cada th del thead.
Así un lector de pantalla para invidentes podría leer esa tabla de forma que tenga sentido para el usuario final, y un usuario cualquiera podrá acceder a todas esas propiedades de la tabla desde las opciones de su navegador.
Vemos que no hemos utilizado ninguna etiqueta de presentación dentro de la tabla; ni fuentes, ni colores, ni fondos, ni bordes, ni espaciados de celdas o contenido, ni nada de eso a que, al menos yo, estaba tan acostumbrado. Eso es tarea del css y lo veremos en un próximo artículo.
Hay más elementos que podríamos utilizar dentro de la definición de una tabla que no he comentado, pero para una completa colección de los mismos y su descripción os recomiendo verlos en w3c.
Desde aquí os animo a abandonar viejas malas costumbres para pasar a utilizar tablas bien formadas y definidas, más accesibles en definitiva.
Life is soft!!
Era una forma fácil de poder hacer que lo que apareciese en los navegadores se asemejara más o menos al diseño gráfico pensado para la web.
Yo también era de esos, planteaba un diseño en Photoshop que luego troceaba y pasaba a Dreamweaver para maquetarlo usando una enorme cantidad de tablas anidadas, lo cual al final ralentizaba la presentación del sitio en los navegadores dada la compleja estructura de tablas anidadas resultantes.
Otro problema subyacente era la accesibilidad. Alguien invidente que utilizase un lector para interpretar esa web fácilmente podía no entender nada de una compleja estructura de tablas que nada tenía que ver con el contenido "real" del sitio web.
Durante un largo periodo de tiempo dedicado a investigar la forma de hacer las cosas en la web me encontré con una escuela de diseñadores web que intentaba separar la forma del contenido, lo cual me interesó mucho por dedicarme básicamente a realizar webs dinámicas donde el contenido está en la base de datos y la forma se encuentra en componentes html que son el front-end para ese medio. Me interesó muchísimo y me puse a estudiarlo.
Así conocí el xhtml + css. Era la nueva web semántica; separación de forma y contenido, la forma se controla mediante css y en el código xhtml no se incluye ninguna etiqueta que tenga que ver con la forma.
Las fuentes y sus tamaños, los colores y fondos, la disposición de elementos, etc, se controla desde css, y el contenido se deja para el código xhtml.
Así las cosas parecía que las tablas eran un elemento a no utilizar en xhtml, pero no es así. Hay elementos claramente tabulares que deben ser mostrados en tablas, que para eso fueron creadas. Así un listado tabulado de información se mostrará utilizando una tabla, un calendario también, y toda aquella información cuya naturaleza sea tabular requerirá de este elemento para ser mostrada.
Las tablas en xhtml no deben ser un tema tabú.
Veamos cómo es una tabla bien formada y accesible.
[table summary="Listado de Repartidores de señal indicando el servicio asociado, las extensiones y pares, así como el elemento D.Hard utilizado"]
[thead]
[tr class="odd"]
[th scope="col" abbr="Repartidor"]Repartidor[/th]
[th scope="col" abbr="Servicio"]Servicio[/th]
[th scope="col" abbr="Extensiones"]Ext.[/th]
[th scope="col" abbr="Pares"]Par[/th]
[th scope="col" abbr="D.Hard"]D.Hard[/th]
[/tr]
[/thead]
[tbody]
[tr]
[td]Ayto. Nuevo - S.S. Yecla[/td]
[td]Jubilados[/td]
[td]2.740[/td]
[td]01[/td]
[td]2.013, 2, 3[/td]
[/tr]
[tr class="odd"]
[td]Parque móvil - Cámaras Becalí[/td]
[td]Bomberos Norte[/td]
[td]4.984[/td]
[td]60[/td]
[td]2.013, 10, 9[/td]
[/tr]
[/tbody]
[/table]
En principio observamos que la tabla tiene un summary que es una descripción de los datos que muestra la tabla. Esto hace que la tabla sea más comprensible.
Debajo del summary podría ir el caption que es el título de la tabla, de forma similar al título de un gráfico de Excel, por ejemplo, para que todos nos entendamos. Este caption también es fácilmente controlable desde css para su aspecto y posición.
Luego pasamos a definir el thead de la tabla que es el grupo de celdas de la tabla que actuarán como cabeceras de columna, como los nombres de columna A, B, C, en una hoja Excel por seguir con la analogía anterior.
En el thead vemos que cada columna cabecera la definimos con th en lugar de td. Esto es así porque esas columnas van a actuar como cabecera de columna y le darán sentido a todos sus td's inferiores.
A continuación del thead podríamos definir de forma similar el tfoot que sería el conjunto de celdas que formarán el pie de la tabla; nota al pie, totalizadores por columna, etc.
Luego viene el tbody, es decir, la "chicha". Aquí es donde van los datos, y se sabe exactamente a qué tipo de dato corresponde cada celda porque lo hemos definido con anterioridad en cada th del thead.
Así un lector de pantalla para invidentes podría leer esa tabla de forma que tenga sentido para el usuario final, y un usuario cualquiera podrá acceder a todas esas propiedades de la tabla desde las opciones de su navegador.
Vemos que no hemos utilizado ninguna etiqueta de presentación dentro de la tabla; ni fuentes, ni colores, ni fondos, ni bordes, ni espaciados de celdas o contenido, ni nada de eso a que, al menos yo, estaba tan acostumbrado. Eso es tarea del css y lo veremos en un próximo artículo.
Hay más elementos que podríamos utilizar dentro de la definición de una tabla que no he comentado, pero para una completa colección de los mismos y su descripción os recomiendo verlos en w3c.
Desde aquí os animo a abandonar viejas malas costumbres para pasar a utilizar tablas bien formadas y definidas, más accesibles en definitiva.
Life is soft!!
miércoles, 9 de enero de 2008
Webs con Velneo
Hace mucho tiempo pregunté en el foro de Velneo por desarrollos web Velneo y me pasaron muy pocas referencias.
El otro día busqué en Google la cadena "cgi-vel" y me aparecieron unas cuantas más.
Aquí las dejo:
http://www.artemisleon.com/
http://www.libroscentral.com/
http://www.uniempleo.com/cgi-vel/uni/ult-ofertas-uni2.bus?_e=25
http://www.hankypankyrecords.com/
http://www.apeti.com/
http://www.hotelesglobales.com/cgi-vel/globales/index.pro
http://www.soriaya.org/
http://www.binariolibros.com/
http://www.destinosfacil.com/
http://www.reinas.es/cgi-vel/reinas/p.pro?p=409
http://www.iberinox.es/cgi-vel/webn/default.pag
http://www.balmat.es/
http://www.alturabeds.com/cgi-vel/thor/home.pro?idi=1&ptr=0&ntr=0&brand=main&u=0
http://www.mastercomputer.es/cgi-vel/vWeb/index.pro
http://www.malagafacil.com/cgi-vel/malagafacil/indexpag.pro?web=1&idioma=2
http://www.asturweb.com/
http://www.ermut.com/cgi-vel/ermut/index.pro?wprog=ekomdhas.htm
http://217.76.137.131:81/index.htm
Hay de todo un poco.
Quizás las que me llamaron la atención fueron la de hankypankyrecords, por la temática, y la de malagafacil (esta parece que tiene un imperio de webs nombre-ciudad_facil.com).
Es reconfortante ver que cada día hay más y mejor.
AH! No olviden visitar también las mías ;-DD
reservaentradas.com
hellovalencia.com
icenter-torrent.es
ccnval.com
Life is soft!!!
El otro día busqué en Google la cadena "cgi-vel" y me aparecieron unas cuantas más.
Aquí las dejo:
http://www.artemisleon.com/
http://www.libroscentral.com/
http://www.uniempleo.com/cgi-vel/uni/ult-ofertas-uni2.bus?_e=25
http://www.hankypankyrecords.com/
http://www.apeti.com/
http://www.hotelesglobales.com/cgi-vel/globales/index.pro
http://www.soriaya.org/
http://www.binariolibros.com/
http://www.destinosfacil.com/
http://www.reinas.es/cgi-vel/reinas/p.pro?p=409
http://www.iberinox.es/cgi-vel/webn/default.pag
http://www.balmat.es/
http://www.alturabeds.com/cgi-vel/thor/home.pro?idi=1&ptr=0&ntr=0&brand=main&u=0
http://www.mastercomputer.es/cgi-vel/vWeb/index.pro
http://www.malagafacil.com/cgi-vel/malagafacil/indexpag.pro?web=1&idioma=2
http://www.asturweb.com/
http://www.ermut.com/cgi-vel/ermut/index.pro?wprog=ekomdhas.htm
http://217.76.137.131:81/index.htm
Hay de todo un poco.
Quizás las que me llamaron la atención fueron la de hankypankyrecords, por la temática, y la de malagafacil (esta parece que tiene un imperio de webs nombre-ciudad_facil.com).
Es reconfortante ver que cada día hay más y mejor.
AH! No olviden visitar también las mías ;-DD
reservaentradas.com
hellovalencia.com
icenter-torrent.es
ccnval.com
Life is soft!!!
Diseño web (paletas de color)
Como ya he dicho en alguna ocasión, el diseño de un sitio web debe correr a cargo de un profesional del diseño gráfico, alguien que partiendo de una hoja en blanco pueda crear un interface que comunique con el usuario de forma atractiva e inteligente, es decir, un diseñador.
En mi caso, no he tenido la ocasión de trabajar con un diseñador a la hora de realizar mis webs, así que he tenido que recurrir a apuntes de diseño gráfico, historia del arte, psicología del color, tutoriales en internet y sobre todo a blogs de diseñadores.
Aparte de las proporciones (diseño áureo, diseño modular), el respeto del espacio en blanco, la elección de la tipografía y su tamaño, uno de los temas que más me han preocupado siempre a la hora de desarrollar el aspecto gráfico de una web es la paleta de color.
La elección de una paleta de colores que resulten en armonía, que comuniquen lo que queremos, que satisfaga y atraiga al usuario, es lo más difícil de todo, al menos para mí.
Un truco que suelo utilizar a veces es una plantilla como la siguiente:
donde dispongo de una rampa de color del blanco al negro con variaciones del 10% en cada paso.
Rellenado con un color base como por ejemplo el #330099 obtenemos una rampa de color desde el blanco hasta el color elegido como base con saltos del 10%:
y si trabajamos con el blanco para el fondo, un casi negro para el texto y dos o tres de estos saltos del color base, ya tenemos una paleta de color para nuestra web que funcionará tan bien como un diseño típico para imprenta a una tinta.
Lo que realmente me sorprende son elecciones de colores, cinco o seis, que teniendo algo que ver o no unos con los otros, al final trabajan bien juntos en un diseño; una paleta de color.
He tenido la suerte de contar desde hace mucho tiempo con los ColourLovers, donde siempre puedes encontar una paleta que te inspire para un diseño determinado.
He recopilado unas cuantas de las que más me han gustado hasta el momento del sitio y las adjunto aquí para que las disfruteis.
Life is soft!!!
En mi caso, no he tenido la ocasión de trabajar con un diseñador a la hora de realizar mis webs, así que he tenido que recurrir a apuntes de diseño gráfico, historia del arte, psicología del color, tutoriales en internet y sobre todo a blogs de diseñadores.
Aparte de las proporciones (diseño áureo, diseño modular), el respeto del espacio en blanco, la elección de la tipografía y su tamaño, uno de los temas que más me han preocupado siempre a la hora de desarrollar el aspecto gráfico de una web es la paleta de color.
La elección de una paleta de colores que resulten en armonía, que comuniquen lo que queremos, que satisfaga y atraiga al usuario, es lo más difícil de todo, al menos para mí.
Un truco que suelo utilizar a veces es una plantilla como la siguiente:
donde dispongo de una rampa de color del blanco al negro con variaciones del 10% en cada paso.Rellenado con un color base como por ejemplo el #330099 obtenemos una rampa de color desde el blanco hasta el color elegido como base con saltos del 10%:
y si trabajamos con el blanco para el fondo, un casi negro para el texto y dos o tres de estos saltos del color base, ya tenemos una paleta de color para nuestra web que funcionará tan bien como un diseño típico para imprenta a una tinta.Lo que realmente me sorprende son elecciones de colores, cinco o seis, que teniendo algo que ver o no unos con los otros, al final trabajan bien juntos en un diseño; una paleta de color.
He tenido la suerte de contar desde hace mucho tiempo con los ColourLovers, donde siempre puedes encontar una paleta que te inspire para un diseño determinado.
He recopilado unas cuantas de las que más me han gustado hasta el momento del sitio y las adjunto aquí para que las disfruteis.
Life is soft!!!
jueves, 3 de enero de 2008
Funciones remotas
Las funciones remotas son esas grandes desconocidas de Velneo, funciones normales y corrientes pero que tienen marcado el check accesible VRPC.
Este hecho permite que sean ejecutadas de forma remota desde otros servidores Velneo invocándolas con un simple
Set -> fr,fEjecutarFuncionRemota( servidor-remoto, alias-aplicacion, funcion-remota, pwd-fr, parametro1, parametro2, ... )
donde
Algo tan simple y sencillo como esto dota a nuestras aplicaciones Velneo de una potencia inusitada, permitiéndonos actualización de datos online desde sitios remotos, replicación de servidores en caliente, consolidación de datos de sucursales en una central en tiempo real, o el uso que realmente se nos ocurra.
Una función remota siempre se va a ejecutar en un servidor Velneo, pero su invocación puede ser desde una aplicación publicada en otro servidor Velneo o desde una aplicación cliente ejecutandose en monopuesto, así un portátil trabajando en local en el coche de un comercial puede comunicar al servidor Velneo de la central las ventas que está realizando, siempre que disponga de conexión a internet, y podría incluso bajarse a local las variaciones de tarifa que
necesitase.
Una función remota, como cualquier otra función en Velneo tiene un retorno. Ese retorno puede ser un simple 1 si se ha ejecutado, un parámetro resultado de un cálculo o extracción de la base de datos, o una ristra de parámetros separados por punto y coma por ejemplo para tener como respuesta un registro entero de una tabla de la base de datos.
Si la función remota no tiene definido un retorno explícito la variable local utilizada para su invocación contendrá un 1 en caso de haberse ejecutado y un 0 en caso contrario.
Un par de cosas a tener en cuenta: el alias-aplicacion y funcion-remota en mayúsculas tanto en su definición como en su invocación, y así nos evitamos problemas.
Condiciones a cumplir con las funciones remotas:
Aquí alguien se puede preguntar; una función remota contra el propio servidor?!! Pues sí. En entornos de desarrollo, para probar una aplicación que ejecuta funciones remotas contra un servidor, si sólo dispones de un servidor para pruebas deberás ejecutar las funciones remotas contra el propio servidor, y en entornos de producción reales yo me he encontrado varios casos donde la ejecución de una función remota contra el propio servidor me ha solucionado más de un problema; enlace gestión-contabilidad, mantenimiento unificado de tablas maestras, etc.
En estos casos hay que evitar que la función remota transaccione sacando la parte del proceso que transacciona a funciones que son llamadas desde la propia función remota.
Hasta aquí hemos visto superficialmente las funciones remotas, su uso y su potencial que vemos que es tremendamente esperanzador ya que nos permite hacer prácticamente todo lo que nos podamos imaginar entre dos aplicaciones Velneo.
Ahora la pega; dos servidores Velneo no pueden ejecutar funciones remotas simultáneas entre ellos, es decir, el servidor 1 no puede lanzar una función remota contra el servidor 2 y a su vez el servidor 2 sobre el servidor 1.
Puede parecer un caso raro y que no vaya a darse nunca, pero en la práctica se da, muy a nuestro pesar. La realidad supera con creces cualquier ficción.
Qué debemos hacer en este caso? Establecer un semáforo, una variable booleana global en disco que condicione la ejecución de las funciones remotas para evitar el "fuego cruzado" entre servidores.
En caso contrario nos encontraremos con dos servidores Velneo bloqueados hasta que uno de ellos se venga abajo. Al tirar abajo uno de los servidores, el otro se recupera y continúa su ejecución como si no hubiese pasado nada.
Como no existe una función específica para acceder al estado del semáforo propio de Velneo al ejecutar funciones remotas, debemos crear y gestionar el nuestro propio. Para acceder al estado del semáforo del servidor remoto lo más sencillo es diseñar un protocolo TCP que informe al otro servidor del estado del semáforo de funciones remotas.
Si la ejecución de la función remota consistiese en la simple petición de un parámetro al otro servidor, como ya tenemos un protocolo TCP establecido entre ambos servidores para la gestión del semáforo, podríamos utilizar el propio protocolo para la transmisión de ese parámetro entre servidores y ahorrarnos la función remota, y el posible problema del "fuego cruzado".
Life is soft!!!
Este hecho permite que sean ejecutadas de forma remota desde otros servidores Velneo invocándolas con un simple
Set -> fr,fEjecutarFuncionRemota( servidor-remoto, alias-aplicacion, funcion-remota, pwd-fr, parametro1, parametro2, ... )
donde
- servidor-remoto es la ip-pública o nombre del servidor remoto donde se va a ejecutar la función remota
- alias-aplicación es el alias con el cual está publicada la aplicación que contiene la función remota que se va a ejecutar en el servidor remoto
- funcion-remota es el nombre de la función accesible VRPC a ejecutar
- pwd-fr es la contraseña de funciones remotas definida en el servidor remoto para la aplicación correspondiente
- parametro1, parametro2, ... son los diferentes parámetros que puede recibir la función remota separados por comas
Algo tan simple y sencillo como esto dota a nuestras aplicaciones Velneo de una potencia inusitada, permitiéndonos actualización de datos online desde sitios remotos, replicación de servidores en caliente, consolidación de datos de sucursales en una central en tiempo real, o el uso que realmente se nos ocurra.
Una función remota siempre se va a ejecutar en un servidor Velneo, pero su invocación puede ser desde una aplicación publicada en otro servidor Velneo o desde una aplicación cliente ejecutandose en monopuesto, así un portátil trabajando en local en el coche de un comercial puede comunicar al servidor Velneo de la central las ventas que está realizando, siempre que disponga de conexión a internet, y podría incluso bajarse a local las variaciones de tarifa que
necesitase.
Una función remota, como cualquier otra función en Velneo tiene un retorno. Ese retorno puede ser un simple 1 si se ha ejecutado, un parámetro resultado de un cálculo o extracción de la base de datos, o una ristra de parámetros separados por punto y coma por ejemplo para tener como respuesta un registro entero de una tabla de la base de datos.
Si la función remota no tiene definido un retorno explícito la variable local utilizada para su invocación contendrá un 1 en caso de haberse ejecutado y un 0 en caso contrario.
Un par de cosas a tener en cuenta: el alias-aplicacion y funcion-remota en mayúsculas tanto en su definición como en su invocación, y así nos evitamos problemas.
Condiciones a cumplir con las funciones remotas:
- Una función remota entre servidores distintos que vaya a transaccionar, debe transaccionar ella misma.
- Una función remota contra el propio servidor que la invoca que vaya a transaccionar, no debe transaccionar ella misma.
Aquí alguien se puede preguntar; una función remota contra el propio servidor?!! Pues sí. En entornos de desarrollo, para probar una aplicación que ejecuta funciones remotas contra un servidor, si sólo dispones de un servidor para pruebas deberás ejecutar las funciones remotas contra el propio servidor, y en entornos de producción reales yo me he encontrado varios casos donde la ejecución de una función remota contra el propio servidor me ha solucionado más de un problema; enlace gestión-contabilidad, mantenimiento unificado de tablas maestras, etc.
En estos casos hay que evitar que la función remota transaccione sacando la parte del proceso que transacciona a funciones que son llamadas desde la propia función remota.
Hasta aquí hemos visto superficialmente las funciones remotas, su uso y su potencial que vemos que es tremendamente esperanzador ya que nos permite hacer prácticamente todo lo que nos podamos imaginar entre dos aplicaciones Velneo.
Ahora la pega; dos servidores Velneo no pueden ejecutar funciones remotas simultáneas entre ellos, es decir, el servidor 1 no puede lanzar una función remota contra el servidor 2 y a su vez el servidor 2 sobre el servidor 1.
Puede parecer un caso raro y que no vaya a darse nunca, pero en la práctica se da, muy a nuestro pesar. La realidad supera con creces cualquier ficción.
Qué debemos hacer en este caso? Establecer un semáforo, una variable booleana global en disco que condicione la ejecución de las funciones remotas para evitar el "fuego cruzado" entre servidores.
En caso contrario nos encontraremos con dos servidores Velneo bloqueados hasta que uno de ellos se venga abajo. Al tirar abajo uno de los servidores, el otro se recupera y continúa su ejecución como si no hubiese pasado nada.
Como no existe una función específica para acceder al estado del semáforo propio de Velneo al ejecutar funciones remotas, debemos crear y gestionar el nuestro propio. Para acceder al estado del semáforo del servidor remoto lo más sencillo es diseñar un protocolo TCP que informe al otro servidor del estado del semáforo de funciones remotas.
Si la ejecución de la función remota consistiese en la simple petición de un parámetro al otro servidor, como ya tenemos un protocolo TCP establecido entre ambos servidores para la gestión del semáforo, podríamos utilizar el propio protocolo para la transmisión de ese parámetro entre servidores y ahorrarnos la función remota, y el posible problema del "fuego cruzado".
Life is soft!!!
Suscribirse a:
Entradas (Atom)
