Avanzis (Blogs Producción)

Trucos FLASH: Obtención de variables desde QueryString

Tue, 12 Aug 2008 14:30:19 GMT

Cada día, en el transcurrir de una empresa dedicada al desarrollo web, ya sea incluso en un mes de agosto, surgen a menudo nuevas especificaciones o requerimientos que nos obligan a investigar soluciones que quizás antes jamás habíamos utilizado. Además esto ocurre frecuentemente cuando se trata de proyectos web que incorporan animaciones en flash, donde en ocasiones la integración e interacción de dicho archivo con nuestro gestor de contenidos requiere del ingenio, da la experiencia, pero sobre todo de la capacidad que actionscript nos ofrece.

Ayer mismo se nos planteó la necesidad de modificar el valor de una variable utilizada en un archivo flash en función del valor de un parámetro del QueryString de una URL. Algo que, tras un par de horas de analisis y de investigación, resulta realmente sencillo de realizar, pero que dicho así de buenas a primeras parece más complejo de lo que es. Aprovecharé además para explicar como de forma sencilla podemos cambiar ciertos aspectos de un mismo fichero flash, solamente mediante el paso directo de parámetros sobre la definición del object.

PASO DE PARÁMETROS DIRECTAMENTE SOBRE EL FLASH

En algunas ocasiones puede interesarnos, sin mayores complicaciones, que un mismo flash se comporte de forma diferente, cambie su color de fondo, o incluso que tenga una apariencia diferente, solamente con cambiar el valor de una de sus variables. Esto, que en apariencia resulta tan absurdo, puede ayudarnos a reutilizar un mismo fichero flash, en varias circunstancias diferentes. Sobre todo es muy útil para ajustar por ejemplo el look and feel de un mismo fichero flash al diseño de distintos portales web.

Ejemplo 1.1: Nuestro fichero flash sustenta su fondo en una fichero de imagen que nosotros podemos cambiar a nuestro antojo. Para ello mediante la simple asignación de una url relativa a la variable imageFileName podremos cambiar dicha imagen de fondo.

codebase="http://macromedia.com/cabs/swflash.cab#version=4,0,0,0"
classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000">


        type="application/x-shockwave-flash height="150" width="250">

Ejemplo 1.2: Con la misma intención que en el anterior ejemplo, esta vez la variable la definimos directamente sobre la propia url relativa de la película flash.

codebase="http://macromedia.com/cabs/swflash.cab#version=4,0,0,0"
classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000">
        value="flaMovie.swf?imageFilename=imagen01.jpg">
    src="flaMovie.swf?imageFilename=imagen01.jpg"
    bgcolor="#99CC33" type="application/x-shockwave-flash
    height="150" width="250">

PASO DE PARÁMETROS POR QUERYSTRING

En nuestro caso en particular lo que necesitábamos es que este paso de variables se hiciera directamente desde el QueryString de una url. Además por cuestiones de optimización optamos porque de todas los posibles variables que puedan encontrarse en el QueryString, tan sólo queremos tener en cuenta la variable definida como tipo, algo que podremos también controlar mediante actionscript.

Ejemplo 2:

import flash.external.*; //para poder usar externalInterface

var paramTipo;
var queryString = ExternalInterface.call("window.location.search.substring", 1);

if(queryString) {
    var allParams:Array = queryString.split('&');

    for (var i = 0, index = -1; i < allParams.length; i++) {
        var keyValuePair:String = allParams[i];

        if((index = keyValuePair.indexOf("=")) > 0) {
            var paramKey:String = keyValuePair.substring(0,index);
            var paramValue:String = keyValuePair.substring(index+1);

            if (paramKey.toLowerCase() == "tipo") { paramTipo = paramValue; }
        }
    }
}

Ya solamente quedará utilizar adecuadamente en nuestro código actionscript la variable definida aquí como paramTipo para la finalidad que fuera necesaria. Con esto lo que logramos, como ya hemos comentado, es poder cambiar dinámicamente nuestra película flash en función de los valores que se han introducido en el QueryString, lo cual nos abre un abanico de posibilidades realmente amplio.

Nota: Este Script solamente funcionará en Internet Explorer si nuestro .swf integrado en el HTML como un Object emebedido tiene previamente definido un id.

Podréis encontrar más información ampliada en inglés en los siguientes enlaces.

Fuente 1 | Circlecube.com
Fuente 2 | Permadi.com

Recomendaciones: Pasar de HTML a XHTML (I)

Sun, 10 Aug 2008 13:39:36 GMT

En muchas ocasiones, cuando se aborda un cambio en el lenguaje de marcado utilizado habitualmente para crear nuestras páginas webs, como es por ejemplo el paso de HTML a XHTML, frecuentemente nos encontramos con problemas de varios tipos, atributos usados de forma indebida, etiquetas mal cerradas, e incluso en algunos casos el comportamiento de los CSS varía, con lo que hay que volver revisarlos y redefinirlos.

Puede parecer, y no falta razón en ocasiones, que los que diseñamos y creamos páginas web ante un cambio de lenguaje de marcado, no nos paramos ni un segundo a estudiar las nuevas reglas de uso y que nos limitamos a dejar que el día a día sea el que nos muestre esos nuevos cambios. Algo que puede tener su origen quizás, en nuestra condición de autodidactas, al menos en mi caso. Ignoro si en el mundo de la programación sucede igual, pero para los que hacemos páginas web creo que éste es uno de nuestros mayores hándicaps, la falta de concienciación sobre las reglas de nuestro lenguaje de marcado.

Ni que decir tiene que el lenguaje de marcado que vayamos a utilizar influye de manera crítica en la forma que nuestro navegador va a interpretar los CSS, una de las piedras angulares sobre los que sustentan nuestros diseños y nuestras páginas web. Es por ello por lo que no está de más conocer cuáles son algunos de los cambios más importantes que XHTML ha incorporado, sobre todo si no queremos que nos afecte a nuestros CSS.

Por ejemplo, una de las nuevas características de XHTML es que es case sensitive. Podríamos pensar que ahí reside uno de los mayores conflictos con CSS, pero este cambio introducido en XHTML, no representa muchas diferencias con lo que se venía haciendo, ya que en HTML la definición de atributos id y class también era case sensitive.

Entonces, ¿por qué el paso de un documento HTML a XHTML deriva en todos estos inconvenientes? La respuesta la podemos encontrar fácilmente en la forma que han tenido y tienen los navegadores de Internet de interpretar el documento que se está abriendo.

La correcta definición en la cabecera de los tipos de los documentos utilizados, ya sean HTML o XHTML, ha sido una práctica poco habitual en el mundo web. Actualmente se ha convertido en algo realmente necesario, sobre todo para que los navegadores apliquen correctamente los estándares y sepan interpretar los documentos de la forma adecuada.

Ejemplo: Definición de un documento de tipo XHTML 1.0 Transitional.

La ausencia de esta definición, derivaba en un conflicto realmente importante con los navegadores de Internet, quienes al desconocer el tipo de documento que estaban procesando, y en lugar de usar al azar alguno de los estándares definidos, el Standar Mode, adoptaban el modo de compatibilidad por defecto, o más conocido como Quirks Mode.

Una de las particularidades de este modo era precisamente no ser case sensitive. Esto afectaba, y sigue afectando, no sólo a la forma de visualizar e interpretar las páginas web, sino a la forma en la que los que desconocían esta circunstancia generaban su código CSS. Siempre ha existido, o al menos esa es mi impresión, la tendencia de diseñar para los navegadores, sin pensar que la solución pasa por diseñar pensando en los estándares. Unos estándares que los propios navegadores ya son capaces de interpretar a la perfección a poco que se lo indiquemos de forma adecuada.

Podríamos decir pues que, al margen de la experiencia de cada uno, no hay nada mejor que saber y conocer perfectamente las reglas, particularidades y características fundamentales del lenguaje de marcado que estamos utilizando. Pero además debemos ser capaces de ver a los navegadores de Internet como lo que son, unos simples intérpretes de nuestro código.

Así, cuando nos topemos de nuevo con la disyuntiva, más que habitual hoy día, de que IE6, IE7, FF2 y FF3 no muestran nuestra página web de la misma forma, sabremos reconocer que quizás el problema sea simplemente que no hemos sabido utilizar de forma adecuada todos los estándares, herramientas y lenguajes de los que disponemos.

Trucos CSS: Optimizando nuestro CSS (II)

Sun, 15 Jun 2008 17:11:57 GMT

Siguiendo con uno de los temas principales abiertos este blog, el que tiene que ver con las cascade style sheet, los CSS, aquí vienen una nueva tanda de trucos y consejos para optimizar nuestro código.

Como ya se ha dicho con anterioridad, hemos de intentar que nuestro archivo CSS sea siempre lo más limpio y organizado posible. Una buena forma de lograrlo es estructurándolo de forma que podamos encontrar fácilmente las distintas clases que hemos definido. Para ello resulta vital la inclusión de comentarios, que pueden cumplir una doble función, informar y a la vez separar o agrupar nuestro código.

Remarcar que los comentarios en CSS se insertan entre las etiquetas /* para indicar el comienzo, y */ para marcar el final del comentario.

Veámos un ejemplo práctico.

Ejemplo 1:

/* === CABECERA ==== */
.HeaderContainer { ... }
.HeaderLink { ... }

/* === PIE DE PÁGINA ==== */
.FooterContainer { ... }
.FooterLink { ... }

Como se puede observar, hemos definido dos líneas de comentarios, que nos agrupan y separan los CSS utilizados en la implementación de la Cabecera por un lado, y los utilizados en la implementación del Pie de página por el otro. Cumpliendo así esa doble función que mencionabamos con anterioridad de organizar e informar.

Además la inclusión de estos comentarios ira creciendo en importancia, a medida que se incrementen las líneas de nuestro código, y el número de atributos CSS que vayamos definiendo. También será importante en el caso de que sean varias las personas que tengan que utilizar y trabajar sobre ese código CSS. Cuanto más conciso, claro y definido sea nuestro código, como ocurre generalmente en programación, mucho mejor.

Recomendaciones: Validar nuestro (X)HTML

Thu, 03 Jul 2008 18:44:06 GMT

En el último post os comentaba la importancia del buen y correcto uso de los estándares en el desarrollo web actual, abordado desde el punto de vista de las hojas de estilos, o más comúnmente conocidas como CSS. Hoy volveré a incidir en la importancia de este asunto, pero esta vez desde la perspectiva de los lenguajes de programación que se utilizan en la composición y creación de nuestro proyecto web.

Como diseñadores web, hemos de ser conscientes de la importancia de utilizar nuestras herramientas de forma totalmente apropiada. Es por ello por lo que si optamos por crear nuestra página web en XHTML 1.0 Transitional o en HTML 4.01 Transitional, por ejemplo, y además así es como lo definimos en la cabecera de nuestro código, parece razonable que procuremos desarrollar basándonos en las reglas que lo definen. Algo que aparentemente parece muy lógico y evidente, pero que no siempre es fácil de recordar y tener en cuenta, sobre todo si el código lo generamos nosotros directamente.

Por suerte, al igual que en el caso de los validadores automáticos de código CSS que ya comentáramos con anterioridad, el World Wide Web Consortium (W3C) también ha creado un excelente servicio para validar el código fuente de nuestro proyecto web. Un validador que automáticamente detecta el tipo de documento con el que estamos trabajando, ya sea XHTML o HTML, y en tiempo real nos muestra los resultados de la validación, remarcando en caso de error la razón por la cual no es aplicable el código invalidado.

VALIDADOR (X)HTML
http://validator.w3.org/

Recomendaciones: Validar nuestro CSS

Thu, 03 Jul 2008 11:41:43 GMT

En el mundo actual del desarrollo web, conceptos como usabilidad, accesibilidad y estándares web se han convertido en inseparables compañeros de viaje para todo aquel que se quiera dedicar a la creación, maquetación y diseño de páginas web, y pretenda además ofrecer a los usuarios y clientes un servicio de calidad.

Muchos de estos conceptos han nacido gracias a comunidades como la World Wide Web Consortium (W3C), que se encarga desde 1994 de guiar, especificar y definir ciertas recomendaciones o buenas prácticas, para tratar de sacar el máximo partido a las posibilidades y capacidades de la web, pero sobre todo para homogeneizar criterios tanto para (X)HTML como para CSS.

Al hilo de estas recomendaciones también se han ido creando y desarrollando interesantes aplicaciones web con el objetivo de actuar como validadores de los estándares web promulgados por el W3C. Algunos de estos servicios automatizan las reglas básicas de (X)HTML o CSS, por ejemplo. Unas herramientas que nos ayudan a saber si, como desarrolladores web que somos, estamos generando un código correcto y conforme a los estándares web del W3C.

VALIDADOR CSS
http://jigsaw.w3.org/css-validator/

Trucos FLASH: Detener un fotograma durante un intervalo de tiempo

Wed, 25 Jun 2008 18:20:54 GMT

Trabajar con Flash supone todo un reto para los que venimos del mundo Web ya que, aunque aparentemente sencillo, la potencia y versatilidad que encierra ActionScript combinado con las posibilidades gráficas que ya de por si ofrece Flash, hacen de esta herramienta un verdadero misterio y quebradero de cabeza para los que somos relativamente ajenos al diseño gráfico.

Por suerte, este no es del todo mi caso, ya que siempre me he sentido atraído por la capacidad y la plasticidad visual de Flash, la que para mi sin duda es la herramienta más utilizada para crear animaciones y llamativos efectos visuales, a la espera del despegue definitivo de Silverlight.

Por ello me atrevo ahora a dar algunos de los trucos o consejos que me han ayudado a sacar el máximo partido de Flash en estos años de uso de la herramienta. Aquí va el primero de ellos...

DETENER UN FOTOGRAMA DURANTE UN INTERVALO DE TIEMPO

Muchas veces, cuando estamos trabajando con una animación, más concretamente cuando queremos pasar de una transición a otra, de un fotograma a otro, puede interesarnos establecer un cierto periodo de pausa justo al cargar el nuevo fotograma, o incluso antes de cargarlo, algo que habitualmente, si somos primerizos e inexpertos, se suele conseguir simplemente añadiendo un mayor número de fotogramas.

No obstante, mediante ActionScript podemos evitarnos la creación de fotogramas innecesarios, manteniendo así un cierto criterio, orden y control sobre las escenas. Además también podremos controlar en todo momento el intervalo de tiempo que queremos que se detenga nuestra animación, sin tener que estar contando fotogramas ni tener que hacer cálculos con los fps.

El código en que deberemos incluir como acción en el fotograma que queremos que se detenga por un intervalo de tiempo es el siguiente:

Ejemplo 1:

    stop();

    function seguir():Void {
        play();
        clearInterval(retardo);
    }

    retardo = setInterval(this, "seguir", 3000);

Donde el valor marcado en negrita es el intervalo de tiempo en milisegundos.

Para los que os interese un poco más saber que se está haciendo con estas líneas de código, deciros que simplemente estamos ejecutando una parada de la animación mediante la llamada a la función stop(). A esto le sigue una llamada a la función setInterval() que es la que se encarga de introducir el retardo tras el cual se realizará una llamada a la función que hemos definido previamente como seguir(). Esta función que hemos creado nosotros y hemos denominado arbitrariamente seguir() es la que se encarga de reanudar la animación mediante la ejecución primero de la función play() y justo después de clearInterval(), que es la que anula y cierra la llamada inicial a setInterval().

Más información sobre las funciones predefinidas aquí utilizadas (en inglés):

stop () : Definición en el Sitio de Adobe Flash
play () : Definición en el Sitio de Adobe Flash
setInterval () : Definición en el Sitio de Adobe Flash
clearInterval () : Definición en el Sitio de Adobe Flash

Trucos CSS: Optimizando nuestro CSS (I)

Sun, 15 Jun 2008 17:11:57 GMT

Como ya comenté en mi presentación, uno de los temas principales que se abordará en este blog es el que tiene que ver con las hojas de estilo, también denominadas cascade style sheet y más conocidas como CSS, el termino que se utiliza habitualmente cuando nos referimos a ellas.

Pues bien, las claves fundamentales a la hora de realizar un archivo CSS es que hemos de intentar siempre, como en cualquier otro lenguaje informático, que nuestro código sea limpio, claro y conciso, pero sobre todo hemos de saber optimizar nuestras líneas de código.

Un buen truco para empezar, muy sencillo, a la par que práctico, consiste en utilizar de forma apropiada y eficiente los atributos de los que disponemos, ya que muchos serán los casos en los que podremos simplificar mediante el uso de un único atributo.

Pero veámoslo mejor con par de ejemplos.

Ejemplo 1:

Tenemos definidos los siguientes atributos para las etiquetas div

div {
margin-top: 10px;
margin-bottom: 5px;
margin-right: 15px;
}

No obstante podemos utilizar directamente el atributo margin (top,right,bottom,left)

div {
   margin: 10px 15px 5px 0px;
}

Como se puede observar, hemos optimizado considerablemente las líneas de CSS utilizadas, y el resultado es el mismo. Este sencillo truco se puede aplicar también al atributo padding.

Veamos otro ejemplo más.

Ejemplo 2:

Definimos los siguientes atributos para las etiquetas table

table {
  border-color: #000000;
  border-style: solid;
  border-width: 10px;
}

No obstante podemos utilizar directamente el atributo border (width,style,color)

table {
   border: 10px solid #000000;
}

Recomendaciones: Plantillas de Dreamweaver

Sun, 08 Jun 2008 11:32:29 GMT

Una de las primeras cosas que aprendí en mi incorporación a Avanzis, porque uno nunca deja de aprender cosas nuevas cada día, fue la utilización de Plantillas Base de Dreamweaver, archivos .dwt, para la creación y desarrollo de un Proyecto Web. Hasta aquel momento todas las Páginas Web que había realizado, meramente corporativas y con apenas un nivel de profundidad, no habían necesitado de mayores exigencias que dos o tres archivos HTML.

Pero a la hora de abordar un Proyecto Web de cierta envergadura, algunos me dirán que es aplicable a cualquier Web en realidad independientemente del tamaño, la necesidad de crear dichas Plantillas se vuelve realmente primordial. Resulta inconcebible por ejemplo, tratar de llevar adelante una Tienda Online, con cientos de productos, y tener que generar desde cero una nueva página HTML por cada uno de ellos. Con las Plantillas podemos definir la estructura principal de nuestra maquetación, y así por ejemplo crear un punto a partir del cual generar los HTML de todos nuestros Productos, pudiendo reutilizar además de manera controlada la mayoría del código necesario, que solo será modificable desde la Plantilla originaria. Del mismo modo podremos habilitar Regiones Editables, que nos permitirán definir nuevas líneas de código en las páginas que creemos a partir de la Plantilla.

Además, otra cuestión realmente curiosa e interesante respecto a los .dwt es que podemos optar por anidar varias Plantillas, con lo que podemos por ejemplo diseccionar las distintas partes de un Proyecto Web, y definir cada una de ellas por separado, heredando eso sí de una Plantilla general donde podemos definir por ejemplo el diseño y la maquetación de la Web.

Adicionalmente con Avanzis Webportal podemos ir un paso más allá mediante la utilización de Controles de Usuario Web de ASP .NET, los denominados ficheros .ascx, con los que podemos además llegar a utilizar un único fichero a partir del cual generar, por ejemplo, el código HTML de todos los productos, logrando así reutilizar el código que nosotros consideremos oportuno en todas nuestras páginas Web. Gracias a Avanzis Webportal los Desarrolladores podemos definir un único fichero .ascx para cada tipología de información, ya sean noticias, productos, galerías de imágenes, lo cual otorga a nuestra Aplicación de una gran capacidad de escalabilidad.

Comparativas: Photoshop vs Fireworks

Tue, 03 Jun 2008 16:09:42 GMT

Cuando llegué a Avanzis, hace ya más de año y medio, se sorprendieron de que a la hora de realizar un diseño gráfico o algún tratamiento de imagen me decantara, sin pensármelo dos veces, por utilizar Photoshop, en sus versiones CS2 y CS3, en lugar de usar Fireworks, herramienta de Macromedia con la que mis compañeros estaban habituados a trabajar.

Mientras, la compra de Macromedia a manos de Adobe ya era un hecho consumado, e incluso habían apuestas por ver cual de los dos productos sobreviría o cual pasaría a mejor vida. Y la realidad es que aunque actualmente todavía conviven ambos, Fireworks ha pasado a un discreto segundo plano.

No obstante, en nuestra oficina sigue siendo la herramienta de edición de imagenes más ultilizada, ya que Fireworks cubre las necesidades básicas de edición o creación que habitualmente se generan, que no son pocas. Por otro lado, nuestro diseñador gráfico, que es quien se encarga de realizar la maquetación para nuestras webs trabaja en Photoshop, y las propuestas y bocetos que realiza nos los pasa siempre en formato PSD.

En mi caso en particular, como ya he mencionado, soy un habitual del Photoshop, algo que quizás se deba al hecho de haber probado antes mil y una herramientas diferentes, desde el Corel Draw pasando por el Paint Shop Pro. Pero tan solo con Photoshop he visto cumplidas mis expectativas y necesidades reales de una herramienta para utilizar en todos los ámbitos del diseño y la edición de imágenes. Digamoslo así me he acostumbrado a usar Photoshop a pesar de su aparente complejidad, repito y recalco, aparente.

Pero, ¿realmente es mejor Photoshop?, ¿o mejor nos quedamos con Fireworks?. Para obtener una respuesta clara, y antes de decidirnos por una u otra aplicación, quizás haya que tener en cuenta dos factores previamente.

El primero de ellos es el nivel de familiaridad con las herramientas de edición de imágenes. Si somos usuarios avanzados, con inquietudes de diseño, y una cierta creatividad, el paso a Photoshop, más que recomendable, resulta necesario. Para el resto, con necesidades más basicas como redimensionar, optimizar, lo más fácil, rápido e inmediato resulta sin duda el uso de Fireworks, ya que en esta herramienta existe un cierto equilibrio entre la facilidad de uso y la calidad en los resultados.

El segundo es el ámbito de utilización. Diseñadores gráficos, maquetadores y publicistas en general usan en su gran mayoría Photoshop, tanto por la cantidad de opciones de retoque fotográfico, las infinitas texturas, la perfección de los acabados, como por la versatilidad de la herramienta, y la necesidad de adaptarse a un formato estandar con las imprentas. Por otro lado, Fireworks parece tener más tirón entre el mundo Web, siendo sin duda su punto fuerte la optimización de las imágenes así como la rapidez y la fácilidad en el manejo.

Pero lo mejor de todo será conocer la visión que el fabricante tiene de su propio producto. Esto es lo que podemos leer en la web de Adobe sobre Fireworks CS3: "Acelere el diseño y el desarrollo de webs con el software Adobe® Fireworks® CS3, la herramienta ideal para crear y optimizar imágenes para la web, así como para diseñar rápidamente prototipos de sitios web."

Curioso ¿verdad?...