Siguiendo con nuestra serie de artículos sobre Google OpenSocial la cual inicio con OpenSocial: introducción a la API social de Google y Primeros pasos con OpenSocial ahora aprenderemos un poco más sobre las aplicaciones sociales con Google OpenSocial.

Para escribir una aplicación social, es necesario que: tengamos acceso a un contenedor que soporte OpenSocial, como Orkut.com y un conocimiento básico sobre el modo de desarrollo de un Google Gadget.

Todas las llamadas a la API de OpenSocial son asíncronas y requerirán de un soporte del lado del servidor para recibir y enviar información sobre las consultas.

Importando la librería OpenSocial:

<ModulePrefs title="Title of Your Application">
  <Require feature="opensocial-0.5"/>
</ModulePrefs>

Agregamos como parámetro FEATURE = “OPENSOCIAL-0.5” a la etiqueta REQUIRE. Un ejemplo sencillo: listando amigos.

Para recibir información debemos crear un objeto DataRequest mediante la función opensocial.newDataRequest(). Una vez creado utilizamos la función DataRequest.add(request) para definir cada tipo de información que queremos recibir.

Después de agregar las petición individuales, procedemos a invocar DataRequest.send(callback). El parámetro de la función indica la función que será ejecutada una vez que se haya recibido la información del servidor. La función toma un parámetro DataResponse, que es el resultado de la petición:

function onLoadFriends(dataResponse) {     // do something with the dataResponse   }
 /**
  * Request for friend information when the page loads.
  */
  function getData() {
    document.getElementById('message').innerHTML = 'Requesting friends...';
    var req = opensocial.newDataRequest();
    req.add(req.newFetchPersonRequest('VIEWER'), 'viewer');
    req.add(req.newFetchPeopleRequest ('VIEWER_FRIENDS'), 'viewerFriends');
    req.send(onLoadFriends);
  };

El último parámetro en la función newFetch*Request() es una variable utilizada para recibir la información de la petición. OpenSocial define los siguientes roles:

• Viewer: el usuario autenticado en el navegador.
• Owner: el usuario al que le pertenece el Gadget en cuestión.
• Friends: usuarios a los que el propietario o visor han agregado a la lista de contactos.

Ahora, veremos las instrucciones de código dentro de la función onLoadFriends():

/**
  * Parses the response to the friend information request and generates
  * html to list the friends by their display name.
  *
  * @param {Object} dataResponse Friend information that was requested.
  */
  function onLoadFriends(dataResponse) {
    var viewer = dataResponse.get('viewer').getData();
    var html = 'Friends of ' + viewer.getDisplayName();
    html += ':<br><ul>';
    var viewerFriends = dataResponse.get('viewerFriends').getData();
    viewerFriends.each(function(person) {
      html += '<li>' + person.getDisplayName();
    });
    html += '</ul>';
    document.getElementById('message').innerHTML = html;
  };

El parámetro dataResponse pasado en la función contiene la información de la respuesta del servidor. La función DataResponse.get(key) regresa cada uno de las peticiones individuales realizadas. El ejemplo completo quedaría de la siguiente manera:

<?xml version="1.0" encoding="UTF-8" ?>
<Module>
 <ModulePrefs title="List Friends Example">
   <Require feature="opensocial-0.5"/>
 </ModulePrefs>
 <Content type="html">

 <![CDATA[

 <script type="text/javascript">

 /**
  * Request for friend information when the page loads.
  */
  function getData() {
    document.getElementById('message').innerHTML = 'Requesting friends...';
    var req = opensocial.newDataRequest();
    req.add(req.newFetchPersonRequest('VIEWER'), 'viewer');
    req.add(req.newFetchPeopleRequest ('VIEWER_FRIENDS'), 'viewerFriends');
    req.send(onLoadFriends);
  };

 /**
  * Parses the response to the friend information request and generates
  * html to list the friends along with their display name and picture.
  *
  * @param {Object} dataResponse Friend information that was requested.
  */
  function onLoadFriends(dataResponse) {
    var viewer = dataResponse.get('viewer').getData();
    var html = 'Friends of ' + viewer.getDisplayName();
    html += ':<br><ul>';
    var viewerFriends = dataResponse.get('viewerFriends').getData();
    viewerFriends.each(function(person) {
      html += '<li>' + person.getDisplayName() + '</li>';
    });
    html += '</ul>';
    document.getElementById('message').innerHTML = html;
  };
  _IG_RegisterOnloadHandler(getData);

  </script>
  <div id="message"> </div>
  ]]>
  </Content>
</Module>

Trabajando con información persistente:

OpenSocial soporta guardar y obtener información por usuario y por gadget. La información almacenada siempre será en formato de cadena de texto, que puede ser tratada como una cadena de texto en formato JSON.

Actividades:

OpenSocial también permite compartir información sobre eventos y actividades. Esto podría expresearse como un activity stream; un feed en donde cada entrada representa un evento. El uso de OpenSocial abre una nueva gama de aplicaciones de colaboración de usuarios en línea y aumenta las características de las aplicaciones.

El uso de OpenSocial abre una nueva gama de aplicaciones de colaboración de usuarios en línea y aumenta las características de las aplicaciones. Esto es solo una pequeñas reseñas del potencial de esta nueva herramienta. Para mayor información pueden consultar el sitio del proyecto.

Fuera del ámbito de desarrollo podemos afirmar que la gran mayoría de las personas quieren conectarse con otros, crear grupos, compartir aficiones y encontrar información de su interés. El punto de afirmación es el gran éxito de las redes sociales. La mayoría de personas quiere compartir con sus amigos. La genialidad de las aplicaciones en estos grupos reside en que tan sencillo y potente me permite conocer lo que quiero saber.

Ahora bien, volviendo al objeto de nuestro estudio, después del repaso del por qué hacer aplicaciones sociales, veamos los cimentos de OpenSocial. Como comentamos en el artículo anterior de la serie, OpenSocial permite el uso de un conjunto de funciones especiales para crear aplicaciones sociales que podrán interoperar con muchos sitios que adopten esta misma API (que son ya varios e importantes, exceptuando FaceBook).

Hay dos maneras de accesar a la API de OpenSocial: utilizando JavaScript del lado del cliente o RESTful? del lado del servidor.

JavaSript API:

La API de JavaScript utiliza opensocial.*namespaces y permite el acceso a tres principales áreas:

• Gente: información sobre una determinada persona y sus relaciones con otros.
• Actividades: permite publicar y ver actualizaciones de lo que la “gente” esta haciendo.
• Persistencia: un simple arreglo asociativo independiente del servidor.

Algunas de las ideas del uso de esta serie de funciones son:

• Construir aplicaciones que no necesiten ser almacenadas en nuestro servidor.
• Construir aplicaciones que incluyan componentes almacenados en el servidor para tareas de sincronización.
• Crear un nuevo conjunto de aplicaciones con nuevas funcionabilidades para nuestros sitios.
• Escribir una aplicación que pueda “correr” en varios sitios.

La API OpenSocial para JavaScript está diseñada para utilizar tecnologías estándar basadas en el Web, permitiendo utilizar librerías desarrollas en lenguaje JavaScript estándar. El paquete incluye un sistema completo de manejo de funciones asíncronas para AJAX.

El paquete RESTful provee funciones complementarias a las funciones de la API JavaScript. La herramienta permite entre otras cosas:

• Interacciones del lado del servidor basadas en el protocolo RESTful AtomPub.
• Auntenticación vía OAuth

Usando la API de OpenSocial:

Otras consideraciones adicionales son listadas en la página del proyecto OpenSocial. Entre las más importantes destacan:

• Las aplicaciones son diseñadas de la misma manera de los Google Gadgets; mediante el edtior de texto favorito o utilizando Google Gadget Editor.
• OpenSocial utiliza JavaScript, HTML y XML estándar; no es necesario el uso de plug-ins.
• Nuestras aplicaciones pueden ser almacenadas en los servidores de Google (según determinadas políticas) o en nuestros propios servidores.
• Es posible embeber Flash en nuestras aplicaciones sociales.
• Para el desarrollo podemos utilizar librerías JavaScript como Dojo, Prototype, JQuery, GWT o la que nosotros consideremos más apropiada. Igualmente, podemos utilizar lenguajes de programación del lado del servidor como PHP, Ruby on Rails, Java, etc.

Primer ejemplo, creando un Google Gadget:

Como mencionamos anteriormente, las aplicaciones sociales están basadas en la misma tecnología que utilizan los Google Gadgets. Ahora, veamos el primer ejemplo de como crear un simple Gadget:

<?xml version="1.0" encoding="UTF-8" ?>
<Module>
  <ModulePrefs title="hello world example" />
  <Content type="html">
     <![CDATA[
       Hello, world!
     ]]>

  </Content>
</Module>

Algunas consideraciones sobre este ejemplo son:

• Un Google Gadget está desarrollado en lenguaje XML. La primera línea denota este punto y debe estar siempre presente en todo documento.
• La etiqueta MODULE indica que el archivo contiene un Gadget.
• La etiqueta MODULEPREFS contiene información sobre el Gadget como título, descripción, autor, etc.
• La línea <CONTENT TYPE = “HTML”> indica que el Gadget contiene información en formato HTML.
• Lo siguiente es el cuerpo del Gadget en formato HTML, predefinido con la clausura CDATA utilizada en documentos XML.

Para obtener más información sobre Google Gadgets puedes vistar la página del proyecto en Google Code. En el último artículo de la serie, se tratará exclusivamente de la creación de una aplicación social utilizando Google OpenSocial.

Todos conocemos a más de una red social de gran éxito. En la actualidad la disputa por el primer lugar está con las redes sociales FaceBook y MySpace a la cabeza y Google se ha sumado lanzando OpenSocial que no es una nueva red social, si no una plataforma de desarrollo, que permite a los sitios sociales administrar una API para conocer los perfiles de sus usuarios en otros sitios y redes sociales.

La propuesta parece ser muy original y esta teniendo gran aceptación. Google OpenSocial fue lanzado el 1 de noviembre de 2007 y desde su comienzo ya contaba con una alianza con los principales sitios sociales ha excepción de FaceBook.

Google OpenSocial provee un set de funciones especiales para el desarrollo de aplicaciones sociales que pueden interactuar en múltiples sitios. El desarrollo de estar aplicaciones sería sencillo de realizar bajo las tecnologías JavaScript y HTML.

Google Orkut (una red social iniciada por un empleado de la compañía) ha sido uno de los primeros sitios que permite a los desarrolladores, probar las aplicaciones basadas en OpenSocial. La iniciativa pretende que las aplicaciones puedan ser almacenadas en los servidores de las redes sociales o en los propios servidores, una idea muy parecida al modo de funcionamiento de las aplicaciones en FaceBook.

Una de las ventajas que señalan los encargados del proyecto en Google, es que OpenSocial es un modelo de programación sencillo que ayudará a los programadores y a los sitios web; por que a los primeros los ayudará a crear aplicaciones que trabajen con cualquier sitio que use la API. Y a los segundos, les permitirá ofrecer estos servicios a sus usuarios como añadido.

Algunos aspectos importantes antes de iniciar:

Las aplicaciones de OpenSocial utilizan la arquitectura de Google Gadgets pero con el añadido de poder utilizar las funciones específicas para OpenSocial. Es decir que antes de iniciar a desarrollar con OpenSocial, deberemos investigar como programar bajo Google Gadgets.

Por ende, al igual que Google Gadgets, una aplicación bajo OpenSocial, está desarrollada mediante documentos en formato XML con HTML/JavaScript como parte del cuerpo del documento. Como se comentaba más arriba, uno de los primeros ambientes de desarrollo es Google Orkut. Una primera idea de la manera en que los desarrolladores podrán probar sus aplicaciones es:

• Abrir la URL sandbox.orkut.com
• Seleccionar Applications en en panel lateral izquierdo
• Pegar la URL de la ubicación del Gadget en la caja de texto Add an application by url

Luego de que hemos instalado la aplicación podemos utilizar y testear la aplicación. Una nota importante es que los archivos de nuestro proyecto deberán estar públicos y accesibles mediante una URL. Podremos instalarlo en un servicio compartido, nuestro servidor o en servicios de alojamiento como Google Pages.

Si hacemos cambios en nuestra aplicación puede que el contenedor de Orkut lo muestre cacheado; por lo que una solución propuesta es que agreguemos una variable en la URL como aleatoria. Internet está cambiando el modelo de negocio de muchos sitios y empresas. En la actualidad, la Web 2.0 demanda un acercamiento entre los usuarios de los servicios y las redes sociales sin duda son la más viva expresión de esta demanda.

Poco a poco nos acercamos al escenario de un mundo más conectado, mediante Internet. Con OpenSocial, podemos interactuar desde nuestra red social favorita con nuestros amigos en otro sitio de interés, de una manera más transparente.

Google OpenSocial es un claro competidor del modelo de FaceBook. La pregunta está en que haremos los desarrolladores frente a estar propuestas. Poder aprovechar el poder de ambas será crucial para poder integrar nuevos servicios a nuestros proyectos.

Lecturas recomendadas:

Para avanzar más sobre el tema te invitamos que leas los artículos: Primeros pasos con OpenSocial y Escribiendo aplicaciones sociales con Google OpenSocial que es parte de está serie de artículos.

Existen bastantes plataformas de desarrollo para diversas tecnologías. Los más sonados son los que interactuan del lado del servidor y en el nivel de programación. Pero YAML es digno de mención por que realmente nos facilita la labor de realizar hojas de estilo.

No debemos confundir el lenguaje de marcado YAML (Yet Another Markup Language) superconjunto de JSON con YAML (Yet Another Multicolumn Layout). Entre las principales características del framework están:

• Un esquema definido de plantillas que incluye una cabecera, un pie de página y un área para una o más columnas muy propio de las nuevas tendencias de diseño.
• Compatibilidad con la mayoría de los navegadores utilizando la plantilla por defecto proporcionada en la distribución.
• Esquemas de diseños fijos o fluidos.

Lo interesante de esta herramienta es que cuando el diseñador inicia a crear la hoja de estilo lo hace con un esquema ya fijado y con la compatibilidad multinavegador. Esta última característica es muy importante a mi parecer. Posteriormente y con el transcurso del diseño de la plantilla el diseñador puede ir restando elementos innecesarios dentro de la hoja de estilo. Pero es importante resaltar que YAML no es una plantilla prediseñada.

Estructura del paquete:

El paquete de distribución incluye la carpeta YAML/ que contiene los archivos necesarios para trabajar con la herramienta. Las demás carpetas son DOCUMENTATION/, EXAMPLES/ y TOOLS/. Dentro de la carpeta YAML están las siguientes hojas de estilo.

• /yaml: contiene los archivos central_draft.css y markup_draft.css. Esta carpeta es la carpeta principal del framework. El primer archivo embebe todos los componentes CSS necesarios para trabajar y el segundo muestra el código fuente de la estructura de YAML.
• /yaml/core: contiene los archivos base.css, iehacks.css, print_base.css, slim_base.css, slim_iehacks.css y slim_print_base.css. Como su nombre lo indica, estos archivos son los componentes base del framework. El primer archivo incluye toda la definición CSS para elaborar un diseño a tres columnas. El segundo (iehacks.css) contiene todos los “ajustes” necesarios para la correcta visualización en el navegador Internet Explorer 5 al 7 independientemente del diseño elegido. Y el tercero proporciona soporte para CSS Print.
• /yaml/screen: componentes CSS para el diseño en pantilla. Incluye los archivos basemod_draft.css y content_default.css.
• /yaml/navigation: componentes para la definición de menús de navegación horizontal y vertical.
• /yaml/print: hojas de estilo con valores por defecto para la definición de la versión imprimible de la página.
• /yaml/patches: mas “ajustes” para Internet Explorer.

¿Cómo empezar a utilizar nuestra plantilla?

Cuando iniciamos el diseño, lo primero que debemos hacer es agregar nuestra plantilla como recurso de hoja de estilo, generalmente utilizando el atributo link. Esta hoja de estilo principal contiene nuestro diseño y la incorporación de las otras hojas de estilo que son parte de YAML mediante la regla @import.

<head>
      ...
      <link href = "css/layout_3col_standard.css" rel = "stylesheet"
            type = "text/css"/>
...
</head>
/* import core styles | Basis-Stylesheets */
@import url(../yaml/core/base.css);
/* import screen layout | Screen-Layout einbinden */
@import url(../yaml/navigation/nav_shinybuttons.css);
@import url(screen/basemod.css);
@import url(screen/content.css);
/* import print layout | Druck-Layout einbinden */
@import url(../yaml/print/print_003_draft.css); 

Reglas de oro para usar YAML correctamente

Las siguientes reglas resumen los principios básicos para el buen desarrollo con YAML:

• YAML no es una plantilla prefabricada.
• YAML está basado en el principio TOP-DOWN (iniciar el desarrollo de la hoja de estilo con definiciones de propiedades estándard para todos los navegadores).
• Todas las plantillas YAML necesitan de tres componentes básicos: base.css, iehacks.css y print_base.css.
• Se debe separar correctamente los archivos del framework, de los propios de nuestro diseño incluyendo los archivos modificados del framework.
• Lee el manual de documentación de YAML antes de iniciar el desarrollo con la herramienta.

El YAML Builder

Adicionalmente en el sitio del proyecto hay un enlace al YAML Builder. Esta aplicación web nos permite definir plantillas en tiempo real y de una manera más gráfica simplificando aún más el proceso de desarrollo de la hoja de estilo. Luego que hemos terminado nos permite obtener una copia de la plantilla lista para poder ser utilizada.

Conclusiones

La idea de utilizar frameworks es debido a la necesidad de agilizar los tiempos de desarrollo de las herramientas. YAML es una muy buena propuesta; útil para aquellos desarrolladores CSS.

La herramienta permite realizar nuestras hojas de estilo de una manera más sencilla, rápida y elegante, combinando propiedades generales y un buen soporte para los navegadores con lo cual no tendremos que ser nosotros los que nos preocupemos por esos detalles que antes nos consumían tanto tiempo valioso.

Les invito a probar por ustedes mismo la herramienta. Para mayor información sobre el proyecto pueden dirigirse a la página web en donde encontrarán el manual de documentación, los archivos del framework y el vínculo al YAML Builder.

En el artículo sobre CSS 3: más social que nunca, hablé sobre las novedades a grandes rasgos del nuevo CSS 3, ahora trataré de detallarlas un poco más con ejemplos de código. Las nuevas propiedades han sido agrupadas en varios módulos según sus prestaciones. La siguiente lista de nuevas propiedades ha sido extraída de CSS3.:

Nuevas propiedades

• Bordes: border-color, border-image, border-radius, box-shadow.
• Backgrounds: background-origin, background-clip, background-size, layering multiple background images.
• Color: HSL colors, HSLA colors, RGBA colors opacity.
• Texto: text-shadow, text-overflow.
• Interface: box-sizing, resize.
• Selectores: attribute selectors.
• Formatos: media queries, multiple column layout, speech.

Backgrounds y Borders:

Entre las principales características destacan que se podrá agregar múltiples background a un objeto, los borders podrán ser redondos con posibilidad de indicar el radio de curvatura.

HTML:

<div class="vcard" vcard">
      <div class="addr-bl" bl">
            <div class="addr-tr" tr">
…
            </div>
      </div>
</div> 

CSS:

.vcard {
      background-color: #000;
      background-image:
      url(a-grad.gif),
      url(a-bl.gif),
      url(a-tr.gif);
      background-repeat:
      repeat-x,
      no-repeat,
      no-repeat;
      background-position:
      0 0,
      100% 0,
      100%;
}

Pueden darse cuenta que en este caso, los múltiples background son agregadas mediante coma ( , ). El nivel de precedencia es de menos a más, es decir, el que está de último es el background de encima.

Multi-column Layout

Ahora será más sencillo crear diseños con múltiples columnas sin etiquetas adicionales. Esta característica me ha parecido extraordinaria y muy útil. En el primer ejemplo, vemos la implementación de esta opción en la versión actual de CSS. Para este caso, debemos crear dos clases CSS y dos objetos DIV para simular la multi-columna.

<div class="entry-content" content">
      <div class="col first">
…
     </div>
      <div class="col">
…
      </div>
</div> 

.entry-content .col {
      float: left;
      width: 467px;
      margin-left: 30px;
} 

.entry-content .first {
      margin-left: 0;
} 

Y en CSS 3 la definición es más sencilla y requiere menos procesamiento

<div class="entry-content" content">
…
</div> 

.entry-content {
      column-count: 2;
      column-gap: 30px;
} 

Advanced Layout:

Esta nueva característica permitirá organizar los elementos en pantalla de una mejor manera y combinarlos de diferentes maneras sin etiquetas adicionales.

Grid Positioning:

Dará la posibilidad que agregar reglas con cuadrículas invisibles para maquetar páginas con un aspecto como libro o revista y jugar con el tamaño y las propiedades de los objetos para hacer que los elementos “floten” entre las posiciones.

<div class="entry-content">

      <h2>What is Sushi?</h2>
…
            <img src="sushi.jpg" class="photo" alt="" />
… 

</div>
.entry-content {
      grid-columns:
            (30px * *)[4];
      grid-rows:
            9em 33.3% *;
      column-count: 4;
      column-gap: 30px;
} 

.entry-content h2 {
      float: page top left;
      width: 6gr;
      height: 1gr;
      margin-left: -30px;
} 

.entry-content img.photo {
      float: page bottom left;
      float-offset: 4gr 1gr;
} 

La respuesta a la pregunta de que si el ejemplo anterior es bastante confuso de entender a simple vista es, sí. En palabras en un poco confuso explicarlo, pero el ejemplo anterior muestra un diseño con cuatro columnas, una foto en medio de la columna 2 y 3 y un titulo de página, todo al más puro estilo de una revista. Así que ya no hay excusas que poner cuando el diseñador nos proponga hacer algo así en HTML.

Selectors:

El concepto de selector es un poco complicado de explicar, y todo debido a que este tipo de propiedades son muy poco utilizadas. Algunos ejemplos de selector que si utilizamos son: :hover y :visited (los selector de hipervínculos). Este tipo de selector podrían ser utilizados en otros elementos y de hecho así puede ser, a excepción del navegador Internet Explorer que no los soporta. Los nuevos selector serían:

• E:only-of-type: un elemento que es único en su tipo.
• E:not(s): un elemento que no coincide con los selector simples.
• E ~ F: un elemento F precedido de un elemento E.
• E:nth-child: un objeto que es el enésimo hijo del nodo padre.
• E:nth-last-child: un objeto que es el último hijo del nodo padre.
• E:nth-of-type: un elemento que es el enésimo nodo hijo de otro elemento.
• E.first-of-type: el primer elemento de un tipo.

Las posibilidades para el uso de selector son realmente muchas. Ahora faltará que la nueva versión de CSS 3 este lista para poder empezar a utilizarla en nuevos desarrollos.

Lecturas recomendadas:

• css3.com
• creatingsexystylesheets.com
• alistapart.com
• trascendingcss.com

CSS 3 ofrecerá grandes cambios y características largamente esperadas por nosotros los webmasters. Lo veremos por todos lados y no viene solo; viene acompañado de HTML 5 y XHTML 2. Los cambios en estas tecnologías obedecen al fenómeno de la Web 2.0 y a las recomendaciones del creador de la World Wide Web, Tim Berners Lee de llevar a la Web a la máxima expresión del concepto de semántica.

Las ventajas de CSS 3:

CSS 2 fue lanzado en 1997 y después de 10 años y alguna que otra actualización, el modelo y propiedades necesita un lavado de cara para obedecer a las demandas del medio. A pesar de eso, realmente debemos mencionar que aún conserva muchas ventajas.

Las ventajas principales en esta nueva versión son la inclusión de nuevas propiedades especialmente en cuanto al aspecto gráfico (recordemos que CSS también es utilizado para describir estilos para medios de audio) aunque se prevean mejores sustanciales en otros medios como el de sonido.

La actualización incluirá los tan esperados bordes redondeados, textos con sombras, la capacidad de asignar múltiples fondos, un mejor manejo de tablas incluyendo el estilo zebra, multi-columnas, etc. El modelo conservará muchas de las actuales propiedades y trabajará con nuevos selectores.

También se habla del hecho de que con estas nuevas propiedades la carga de la página deberá descender pues el hecho de que muchos de los efectos estén ahora bajo control del navegador hará que los recursos visuales e imágenes que ahora empleamos ya no tengan razón de seguir siendo utilizados.

Capacidades visuales avanzadas:

CSS 3 contiene varias mejoras en cuanto a interfaz gráfica, posicionamiento y tamaño de los objetos, usando condiciones de alineación para cada uno. El objetivo es que sea más sencillo posicionar los controles dentro de la página y que cuenten con otras características como desplazamiento.

Hojas de Estilo Aural:

Pretende utilizar las opciones de ciertos dispositivos con capacidades de reproducción de sonido. El módulo de audio podría agregar sonidos de fondo o efectos de transición que se activarían mediante determinado evento. Otras propiedades permitan controlar la posición del sonido que se está reproduciendo, etc.

Bordes y Fondos:

Las nuevas capacidades de CSS 3 permitirían entre otras cosas usar imágenes para los bordes, redondear y/o agregar sombras. Posicionamiento de elementos en pantalla: se podrá controlar de mejor manera los objetos y su dirección (horizontal o vertical).

Además, se quiere incluir el módulo de paginación para crear pies de página, referencias cruzadas y construir cabeceras para títulos de secciones. También se desea introducir una nueva propiedad para dividir secciones en columnas.

Fuentes:

Nuevas funciones sobre todo encaminadas a brindar un mejor soporte a múltiples lenguajes. Se pretende volver a incluir el @font-face para utilizar fuentes externas.

Otros cambios sustanciales serían un mejor modelo para trabajar CSS con DOM incluyendo la posibilidad de cambiar valores a las propiedades, uso de NAMESPACES como XML y la inclusión de un mejor soporte para manejo de expresiones matemáticas.

Roadmap de soporte de CSS 3 para los navegadores

Lo que deberemos tomar en cuenta es que antes de saltar a empezar a migrar nuestro sitio a la versión CSS 3 la mayoría de los navegadores ya hayan implementado parte de estas nuevas especificaciones.

Actualmente el desarrollo va con el navegador Opera a la cabeza seguido de WebKit. Opera 9.x incluso ya viene con soporte para los nuevas etiquetas de HTML 5. Mozilla y Microsoft aún no han presentado mayores cambios en sus exploradores Firefox e Internet Explorer, respectivamente.

Por otro lugar el equipo de desarrollo de WebKit (donde podemos incluir a Konqueror y Safari) estado trabajando en dar soporte a estas nuevas propiedades. Los cambios también incluyen el regreso de la propiedad @font-face que permite la carga de un recurso tipográfico (es decir una fuente TTF) como de una imagen se tratase.

Esta propiedad fue incluida en la especificación de CSS 2.0 y eliminada de la lista bajo la excusa de no ser utilizada. Los primeros en brindar el soporte a esta propiedad es el equipo de WebKit mediante un plugin.

Qué esperar con CSS 3

Esperamos que en el 2008 la mayoría de navegadores incluyan dentro de alguna actualización el soporte nativo para CSS 3 y las nuevas versiones de HTML y XHTML. Por lo pronto, debemos de esperar un poco más, leyendo uno que otro documento que sale al respecto para prepararnos por que la salida de esas nuevas versiones esta mas cerca cada día.

El tema sobre CSS 3 es más extenso, así que hemos preparado varios artículos que te guiarán paso a paso sobre sus propiedades y aprovechamiento. Además, un ejemplo sobre una futura implementación dentro de hojas de estilo CSS 3.

CSS nació de la propuesta de dividir la estructura del documento de su diseño. La problemática que se venía dando en el viejo orden era que los documentos eran muy difíciles de mantener. Si por ejemplo, suponemos un sitio con alrededor de 100 o más documentos el cambiar el diseño a cada uno era muy laborioso.

De esto ha pasado algún tiempo y las exigencias han cambiado. El uso de CSS se ha hecho más cotidiano tanto que ya es un estándar. Como en todo desarrollo, cuando separamos componentes estamos ahorrándonos tiempo y esfuerzo. CSS es ideal para todos los proyectos no importando su tamaño.

Clases y valores por defecto:

Hace algún tiempo leí acerca de este tema en el sitio de Shapead y me llamó la atención tanto, que preparé la traducción. A manera general el tema mostraba las razones para definir valores por defecto para la hoja de estilo que estamos utilizando.

Como muchos sabemos existe un gran variedad de navegadores en el mercado y cada uno trabaja de manera distinta. Aparte de que cada navegador tiene características particulares, trae consigo distintos valores por defecto para los documentos.

La gran ventaja de utilizar esta técnica es que nos permite llevar el desarrollo de nuestra plantilla de una manera más estándar. Por ejemplo, es recomendable definir los valores por defecto de los márgenes y de las sangrías, el tipo de letra, el interlineado, etc. Para que todos los navegadores muestren en la misma posición los elementos en pantalla.

Además es un técnica interesante el ir creando clases generales con nombres característicos que establezcan valores como el texto de decoración de la letra, el espaciado, etc. Con lo cual nos evitamos ir definiendo mismas propiedades para elementos distintos.

También, podemos definir y reutilizar valores de clases para ir creando los estilos en una especie de propiedades con herencia y que conforme vaya especializándose el diseño para un objeto; se vaya añadiendo propiedades específicas para el mismo.

Técnicas para modelar la hoja de estilos:

Es gracioso que cada webmaster tenga un modo particular de modelar su hoja de estilos. Existen varios puntos a cubrir como:

El orden en que se escriben las clases y propiedades: una de las técnicas más populares es ir dividiendo por secciones a la vez de ir comentando ciertos puntos y clases dentro del CSS. También podemos encontrar el caso de ordenar las clases por tipo y alfabéticamente (tanto nombres de clases como propiedades).

Crear un archivo CSS aparte por cada navegador con ajustes a las clases CSS que definitivamente no pudieron estandarizarse o utilizar los famosos hacks por navegador (una medida algo desesperada; aunque divertida).

Los nombres de las clases: casi todos coinciden en que es importante que los nombres de las clases sean descriptivos y que denoten incluso el ámbito en el que actúan en la página. Una buena técnica podría ser ir definiendo la clase de lo general a lo específico como: news_title_tiny ó administrator_menu_subitem.

Hojas de estilo para varios navegadores:

Al tener tantos navegadores con diferentes características es inevitable que el diseño que estamos realizando no se vea bien en alguno de ellos. En mi caso; cada vez que voy realizando cambios en la hoja de estilo voy probando continuamente en cada uno de los navegadores como se muestra la página.

Una buena implementación de CSS no contendrá ajustes o hacks. Aunque muchas veces esto es inevitable, es necesario que conforme nuestra experiencia avanza, vayamos disminuyendo el uso de este tipo de técnicas que muchas veces se salen de los estándares.

Si separamos correctamente HTML de CSS, cuando quitemos la referencia a la hoja de estilo, este deberá verse y leerse de manera vertical sin ningún tipo de diseño. Esto es una característica que también nos permitirá aplicar de mejor manera las técnicas SEO.

Algunas propiedades olvidadas de CSS 2

Para quienes utilizamos editores con soporte CSS y la característica Smart Tags el ver propiedades que nunca utilizamos en la lista seguro que nos intriga. Por qué será que casi nunca las utilizamos: talvez es desconocimiento o simplemente su uso está fuera de foco. Para cualquiera de los dos casos aquí preparo una lista de algunos de esos elementos perdidos en CSS 2:

• azimuth: indica el ángulo horizontal o lateral del sonido en hojas de estilos Aural.
• caption-sice: al igual que la anterior pertenece al orden de las propiedades para hojas de estilo Aural. Su objetivo es posicionar el elemento caption de una tabla arriba o abajo.
• clip: esta propiedad me ha llamado mucho la atención. El objetivo de la misma es mostrar una región de un elemento posicionable (con atributo position: absolute). En CSS 2 la única forma que admite es un rectángulo pero se tienen planes de extender el soporte a otras formas. Me ha parecido muy parecida, en cuanto a manejo y comprensión al elemento MAP.
• column-span: el equivalente a COLSPAN para elementos TD.
• content: este atributo es bastante peculiar y definitivamente sale del estándar de separar el contenido del diseño. Funciona solamente con las seudoclases cue-before y cue-after. Su objetivo es poder incluir contenido HTML antes o después de la definición del objeto.
• direction: permite definir la posición del texto de un elemento: es decir ya sea de izquierda a derecha o viceversa. Actualmente no es soportada por ningún navegador.
• elevation: tiene un funcionamiento similar a azimuth.
• filter: para muchos no es una propiedad desconocida. Es la encargada de aplicar filtros de efectos a los elementos CSS y solo está disponible para Internet Explorer. Con ella se logra es famoso efecto de transparencia de imágenes PNG en versiones anteriores a Internet Explorer 7.
• letter-spacing: establece un espacio de separación entre letras.
• orphans: indica el número mínimo de línea que debe tener un párrafo que debe ser visible en la parte inferior de la página cuando ocurre el salto de página. Generalmente utilizado para impresiones.
• page-break-after, page-break-before: define el comportamiento del contenido para el salto de página cuando el documento es enviado a la impresora.
• pause, pitch, play-during, richness, speak, stress y voice-family: controles del sonido para hojas de estilo tipo Aural.
• size: define el tamaño y la orientación del papel para la impresión.
• text-indent: determina el tamaño de la sangría en la primera línea del párrafo.
• widows: el mismo propósito de orphans, pero en la posición de arriba del elemento.

Conclusiones:

CSS es muy interesante y posee muchas cualidades. CSS no es solamente utilizado para hacer el diseño de la página sino también de otros elementos como la versión imprimible y herramientas para voz. Muchos dicen acerca de la necesidad de diseñar la versión imprimible de la página. Ahora que vimos los elementos olvidados también podemos incluir la versión escuchada.

CSS está evolucionando y ahora esta próximo el lanzamiento de la tan esperada versión 3 que incluye muchas nuevas características ya solicitadas hace mucho tiempo incluyendo el regreso de @font-face para aquellos amantes de la era Web 2.0 y de las tipografías.

NOTA: para quienes no sabíamos que eran las hojas de estilo Aural (así como yo, antes de escribir este artículo), les comento que este tipo de CSS es utilizado cuando la hoja de estilo describe las propiedades del sonido. Como podemos recordar CSS puede ser utilizado en el medio de Internet, para Impresiones y para describir el comportamiento en medios de reconocimiento de voz y sonidos.

Concluimos con nuestra serie sobre Smarty en donde hemos abordado los temas sobre, Smarty: razones para utilizar plantillas en mis proyectos, Smarty: requerimientos, instalación y aprende a programar, Smarty: a nivel avanzado y ahora hablaremos de sus alternativas.

Sistemas de Plantillas en PHP

Savant:

El proyecto Savant es un sistema de plantillas que me ha parecido bastante interesante. Savant está basado en el paquete PEAR. A diferencia de Smarty el archivo de plantilla no es un archivo con una sintáxis diferente sino otro archivo PHP.

Una ventaja en cuando a rendimiento, aunque definitivamente podría generar problemas en especial si lo utilizamos en un proyecto donde el encargado de la integración con HTML no es conocedor de lenguaje PHP.

Tiene varias similitudes con Smarty en cuanto a convención de nombre de funciones del objeto y al manejo de concepto de carpeta de plantillas. El hecho de que la plantilla final sea PHP permite que pueda utilizar las variables y funciones de nuestro script original, pero a mi parecer también genera una gran vulnerabilidad.

Ejemplo: Script PHP

<?php
//  this gets the template output from the template search path.
$output = $tpl->fetch('template.tpl.php');
// this would display another template from a subdirectory
// in the template search path.
$output = $tpl->fetch('subdir/anotheryawiki_storelate.tpl.php');
// an alternative method: set the default template
// and then return the default script output.
$tpl->setTemplate('template.tpl.php');
$output = $tpl->fetch();
?>

Plantilla:

<html>
      <!-- template source -->
      <?php include $this->loadTemplate('header.tpl.php') ?>
      <h2>Main Content</h2>
      <p>Your name is <?php echo $this->name ?>, right?</p>
      <?php include $this->loadTemplate('footer.tpl.php') ?>
</html>

Sistemas de plantillas para Ruby

Canny:

Esta fantástica implementación del motor de plantillas Smarty para lenguaje Ruby. Los desarrolladores del proyecto han cuidado que la aplicación sea igual en cuanto ha implementación de lógica de programación y sobre todo que las plantillas que han sido creadas para Smarty puedan utilizar Canny como motor de compilación.

Aunque hay algunas variantes a nivel de plantilla sobre todo por el manejo que se le da a los tipos de datos. Realmente un gran proyecto.

Ejemplo: Script Ruby

#!/usr/bin/env ruby
require "Canny"
# Inicia el objeto Canny y asigna los directorios de plantilla
C = Canny.new
C.template_dir = 'templates'
C.compile_dir  = 'templates_c'
name = 'Canny user'
people = [
          {'name' => 'John Doe', 'city' => 'New York', 'zip' => '10000'},
          {'name' => 'Jane Doe', 'city' => 'Los Angeles', 'zip' => '90000'},
      ]
fruits = ['Apple', 'Orange', 'Banana', 'Strawberry', 'Cherry', 'Lemon', 'Lime']
def my_modifier(str, params=[])
     if params[0] == ‘pie’
          str += ” Pie”
     elsif params[0] == “smoothie”
          str += ” Smoothie”
     else
          str
     end
end
Canny.register_modifier(’my_modifier’, ‘my_modifier’)
C.assign(’name’, name)
C.assign(’people’, people)
C.assign(’fruits’, fruits)
C.display(’example.tpl’)

Ejemplo: Plantilla (prácticamente es la misma sintáxis que Smarty).

Hello { $name }.
<br />
<br />
{ foreach from=$fruits item=fruit }
     { if $fruit == "Apple" or $fruit == "Cherry" }
          { $fruit|my_modifier:"pie" }
     {else}
          { $fruit|my_modifier:"smoothie" }
     {/if}
     <br />
{/foreach}
{ foreach name=people from=$people item=person }
     { $canny.foreach.people.iterator } { $person.name|upper } lives in { $person.city|upper }.
     <br />
{/foreach}
<br />
<br />
{ include file="example_show_total.tpl" total=$canny.foreach.people.total }

XTemplate:

Esta es otra alternativa en lenguaje Ruby, XTemplate es un sistema de plantillas basado en XML. Su funcionamiento en bastante interesante aunque, por lo que he visto en cuanto al modo de funcionamiento y su sintáxis es viable en proyectos robustos y con un grupo de profesionales en manejo de estructuras con XML.

Los ejemplos que he consultado para hacer esta pequeña reseña no dan muestras de ser un sistema que separe las plantillas en archivos aparte, aunque si es muy seguro que se logre emular esta opción mediante inclusiones de scripts.

Ejemplo: Ruby

require 'xtemplate'
data = {
  'members' => [
    {"name" => "name1", "age" => 20},
    {"name" => "name2", "age" => 23},
    {"name" => "name3", "age" => 30},
  ],
  ‘operators’ => [
    {"name" => "op1", "age" => 28},
    {"name" => "op2", "age" => 32},
    {"name" => "op3", "age" => 24},
  ],
} 

Ejemplo: de la Plantilla (dentro del mismo script)

text = <<EOF
<?xml version="1.0" encoding="UTF-8"?>
<members xmlns:xt="http://xtemplate.sourceforge.net/xtemplate">
  <member xt:id="/members{push(stack1)}|/operators{pop(stack1);sort(age)}/name">
  </member>
  <xt:value-of id="/members{push(stack2)}" />
  <xt:value-of id="/members{push(stack2)}" />
  <member xt:id="/operators{pop_all(stack2)}/name">
  </member>
  <xt:value-of id="/members{push(stack3)}" />
  <xt:value-of id="/members{clear_stack(stack3)}" />
  <member xt:id="/operators{pop_all(stack3)}/name">
  </member>
</members>
EOF
t = XTemplate::XMLTemplate.new(text)
print(t.expand(data))

Ejemplo: salida

<?xml version="1.0" encoding="UTF-8"?>
<members>
  <member>name&</member>
  <member>name&</member>
  <member>name&</member>
</members> 

En cuanto al manejo de sintáxis lo veo bastante interesante, con fuertes tendencias a la generación de archivos XML o con marcado. Una característica es que la plantilla puede utilizar marcado XML o YAML (recordemos que Ruby viene con un Parser integrado de YAML).

Motores de plantillas en lenguaje Java

Velocity:

Proyecto impulsado por The Apache Foundation Software. Velocity es un sistema basado en Java que permite a los diseñadores importar métodos en lenguaje Java a la plantilla para generar documentos HTML, SQL, PostScripts, etc.

FreeMaker:

FreeMaker, es otro sistema de plantillas para Java que permite generar documentos en formato HTML, RTF, PostScript, TeX, etc) y que permite ser integrado con Java Servlets, XML, Python y otras tecnologías.

ASP.Net y Joel.Net, plantillas free open-source

Joel.Net es un sistema bastante interesante de plantillas para ASP.Net. Actualmente trabaja en VB.Net y C#. Este software es lanzado bajo licencia JPL. La instalación del componente es bastante sencilla y muy parecida a la instalación de otros módulos en Visual Studio.Net aunque tambíen puede ser instalado como módulo independiente.

Ejemplo:

<!-- template.html -->
<HTML>
  <HEAD><TITLE>No Title</TITLE></HEAD>
  <BODY bgcolor="#FFFFFF">
    <TABLE border="0">
      <TR>
        <TD><tem:navigation>navigation</tem:navigation></TD>
        <TD><tem:main /></TD>
      </TR>
      <TR><TD colspan="2">
        <tem:footer>Copyright joel.net 2003.</tem:footer>
      </TD></TR>
    </TABLE>
    <BR><BR>
  </BODY>
</HTML>
<!-- page.aspx -->
<%@ Register TagPrefix="cc1" NameSpace="template" Assembly="template" %>
<cc1:template id="Template1" runat="server" path="./template.html" />
<asp:Panel id="tem_main" runat="server">
  <B>This should go in the main section!</B>
</asp:Panel> 

Conclusiones

Hemos visto sólo algunos de la gran diversidad de proyectos similares a Smarty en diversos lenguajes. La mayoría emplean una sintáxis similar de plantillas y otros como el caso de Java que utiliza XML para definir la plantilla (que en modo particular me a parecido bastante interesante).

También, vale la pena mencionar a Joel.Net que es un sistema bastante sencillo de utilizar para desarrolladores en ASP.Net y cuyo punto a favor es el ser libre y código abierto. Cada uno de los desarrollos en distinto y las alternativas vistas aquí son válidas.

En modo muy personal optaría por Smarty en desarrollo con PHP pues a demostrado ser un sistema muy bueno y con grandes prestaciones. Igualmente, su proyecto en Ruby, Canny merece ser considerado para desarrolladores en este lenguaje.

Cada grupo deberá escoger el que más considere adecuado para su proyecto. Incluso, muchos optarán por no utilizar ningún sistema de plantillas. Eso queda muy a discreción del grupo de programadores. Aunque el proyecto sea algo pequeño, siempre es una buena práctica utilizar plantillas para separar la lógica de programación y el diseño.

Siguiendo con nuestra serie de artículos: Smarty: razones para utilizar plantillas en mis proyectos, Smarty: requerimientos, instalación y aprende a programar, ahora nos corresponde hablar sobre Smarty pero a nivel avanzado. Smarty cuenta con estructuras de control propias, cuando compilamos nuestra plantilla, verificará que no haya sido procesada antes, haciendo que la carga sea más rápida.

En la carpeta definida para los archivos compilados de las plantillas encontraremos el código PHP. Lo que demuestra que aunque la plantilla original tenga una sintaxis distinta, el archivo generado y ejecutado es un archivo PHP.

Calificadores Smarty

En todo lenguaje existen los calificadores, que permiten hacer comparaciones entre variables. Smarty tiene los propios un tanto distintos a los que estamos acostumbrados:

Tabla: para los operadores lo recomendable es utilizar las alternativas, pero también es permitido utilizar los calificadores originales. Para los operadores AND / OR puede utilizarse el operador lógico (and / or) o && (and) / | | (or).

Estructuras de control en Smarty

Sentencia IF:
{if $name eq "Fred"}
      Welcome Sir.
{elseif $name eq "Wilma" or $name eq "Vilma"}
      Welcome Ma'am.
{else}
      Welcome, whatever you are.
{/if} 

Sentencia SECTION:

Las section del template son usadas para realizar un ciclo (loop) de un arreglo de datos. Todas las etiquetas {section} deben tener su par {/section}. Los parámetros requeridos son name y loop. El nombre de la section puede ser el que usted quiera, formado por letras, números y subrayados.

Las sections pueden ser anidadas pero diferenciando unas de otras. Las variables del loop (normalmente una matriz de valores) determina el número de veces del loop de la section.

Cuando estuviera mostrando una variable dentro de una section, el nombre de la section debe estar al lado de la variable dentro de corchetes []. sectionelse es ejecutado cuando no hubiera valores para la variable del loop(ciclo).

<?php
      $data = array(1000,1001,1002);
      $smarty->assign('custid',$data);
?>
{* este ejemplo imprime todos los valores del arreglo *}
{section name = customer loop = $custid}
      id: {$custid[customer]} <br />
{/section}
<hr />
{* imprime todos los valores del arreglo en orden descendente *}
{section name=foo loop=$custid step=-1}
      {$custid[foo]} <br />
{sectionelse}
      no hay valores en la variable
{/section} 

También, puede hacerse un ciclo sin un arreglo para tratar. Este ejemplo iniciará el contador en 10 e irá de 2 en 2 hasta el número 20:

{section name = foo start = 10 loop = 20 step = 2}
      {$smarty.section.foo.index}
{/section} 

Sentencia FOREACH:

Los ciclos foreach son una alternativa para loop {section}. Foreach es usado para pegar cada elemento de una matriz asociativa simple. La sintaxis para foreach es mucho más simple que section, pero tiene la desventaja de que solo puede ser usada en una única matriz, la etiqueta {foreach} debe tener su par {/foreach}.

Los parámetros requeridos son from e item, el nombre del ciclo foreach puede ser cualquier cosa que usted quiera, hecho de letras, números y subrayados. Los ciclos foreach pueden ser anidados, y el nombre de los ciclos anidados, debe ser diferente uno de otro. La variable from (normalmente una matriz de valores) determina el número de veces del ciclo foreach, el cual será ejecutando cuando no hubiran más valores en la variable from.

<?php
      $arr = array( 1001,1002,1003);
      $smarty->assign('custid', $arr);
?>
{* este ejemplo muestra todos los valores de la matriz $custid *}
{foreach from = $custid item = curr_id}
      id: {$curr_id}<br />
{/foreach} 

Recordemos que para arreglos asociativos, el signo de separación es el punto ( . ). Además, existe un conjunto de propiedades disponibles dentro del ciclo, como el número de interacción, la llave asociativa, etc.

Otras funciones dentro de la plantilla Smarty:

Smarty tiene un conjunto de funciones integradas bastante grandes, enumerar cada una de ellas con sus características y mostrar un ejemplo, haría que este artículo fuese demasiado extenso. A continuación, muestro un listado de algunas funciones interesantes y una pequeña descripción:

• include_php: Incluye un archivo PHP dentro de la plantilla. Util para obtener información de otros recursos.
• capture: es usado para recolectar toda la salida del template en una variable en lugar de mostrarla.
• ldelim, rdelim: son usados para escapar delimitadores en el template, en nuestro caso “{” or “}”.
• literal: permite que un bloque de texto sea tomado literalmente, no siendo interpretado por Smarty.
• php: incrusta código PHP dentro de la plantilla. No recomendado.
• assign: Es usado para definir valores a las variables de template durante la ejecución del template.
• cycle: es usado para hacer un ciclo a través de un conjunto de valores. Esto hace mas fácil alternar entre dos o mas colores en una tabla, o ciclos a travéz de una matriz de valores.
• html_*: funciones especiales para tratamiendo de cuadros de selección, imágenes, listas de selección, cuadros de fecha, etc.
• math: soporte para definición de funciones matemáticas.
• mailto: soporte automátizado para creación de vínculos de correo electrónico con posibilidad de codificación.

Extendiendo Smarty con Plugins:

Smarty puede ser personalizado, agregando nuevos plugins con lo cual automatizamos funciones para ser utilizadas dentro del template.

Podemos agregar nuestros propios scripts para extender: funciones, modificadores, funciones de bloque, funciones de compilación, prefiltros, postfiltros, filtros de salida, recursos e inserts. Generalmente escribiremos funciones y modificadores.

Nombres convencionales

Los archivos y funciones de Plugin deben seguir una convención de apariencia muy especifica a fin de que pueda ser localizada por el Smarty. Los archivos de plugin deben ser nombrados de la siguiente forma: type.name.php. Donde type es uno de los siguientes tipo de plugin:

• function
• modifier
• block
• compiler
• prefilter
• postfilter
• outputfilter
• resource
• insert

Algunos ejemplos: function.html_select_date.php, resource.db.php, modifier.spacify.php. Las funciones de plugin dentro de los archivos de plugin deben ser nombradas de la siguiente forma: smarty_type _name() .

<?php
      /*
       * Smarty plugin
       * -------------------------------------------------------------
       * File: function.eightball.php
       * Type: function
       * Name: eightball
       * Purpose: outputs a random magic answer
       * -------------------------------------------------------------
       */
      function smarty_function_eightball($params, &$smarty)
      {
            $answers = array('Yes',
                             'No',
                             'No way',
                             'Outlook not so good',
                             'Ask again soon',
                             'Maybe in your reality');
            $result = array_rand($answers);
            return $answers[$result];
      }
?>
Question: Will we ever have time travel?
Answer:   {eightball}. 

Ahora bien, debemos reconocer que no existe solamente Smarty como motor de plantillas, sino que existen muchas más alternativas de proyectos con características similares y otras funcionabilidades.

En el próximo artículo y final de la serie sobre Smarty, enumeraremos cuales son esas alternativas junto con sus principales características. En fin, Smarty demuestra ser una herramienta valiosa, open-source y con una gran capacidad de expansión.

En el artículo Smarty: razones para utilizar plantillas en mis proyectos les hablé sobre las principales características y razones por las que es importante conocer Smarty. También hablamos acerca de sus capacidades de una manera muy general. En este nuevo artículo veremos por qué considerar Smarty para nuestros proyectos y cómo empezar a utilizarlo.

Requerimientos

Smarty requiere un servidor web corriendo PHP 4.0.6 o posterior. Para obtener los archivos debemos descargarlos desde la página del proyecto Smarty. Ahí se encontrará la última versión del mismo.

Método de instalación

Existen varios métodos para instalar Smarty en nuestro proyecto, cuando hemos descargado el paquete comprimido, encontraremos una serie de carpetas. Los scripts del sistema están en el directorio de distribución /LIBS/. Smarty puede ser instalado en una carpeta fuera del directorio raíz dentro de nuestro servidor (configurando la directiva include_path en el archivo php.ini) o estar en una carpeta dentro de la estructura de directorios del sitio. Lo importante es que cuando creemos el objeto referencia, el interprete pueda localizar el archivo base Smarty.class.php:

<?php
      # Ejemplo de inclusión del archivo Smarty.class.php y creación del
      # objeto Smarty
      require('/path/relativo|absoluto/Smarty.class.php');
      $smarty = new Smarty;
?>

Smarty utiliza cuatro directorios para procesar las plantillas: templates/, templates_c/, cache/ y configs/. Los directorios templates_c/ y /cache necesitan permisos de lectura y escritura. Estos directorios son por defecto, pero cuando se crea la instancia del objeto, pueden definirse en tiempo de ejecución:

<?php
      require('Smarty.class.php');
      $smarty = new Smarty;
      $smarty->template_dir = '/smarty/templates/';
      $smarty->compile_dir = '/smarty/compiles/';
      $smarty->config_dir   = '/smarty/configs/'
      $smarty->cache_dir    = '/smarty/cache/';
      $smarty->assign('name','Ned');
      $smarty->display('index.tpl');
?>

Sintáxis básica:

Todas las etiquetas del template deben estar marcadas por delimitadores. Por defecto, estos delimitadores son { y }. En Smarty, todo el contenido fuera de los delimitadores es mostrado como contenido estático o igual (sin cambios). Cuando Smarty encuentra etiquetas en el template, trata de interpretarlos e intenta mostrar la salida apropiada en su lugar.

Cuando incluimos código en JavaScript o CSS dentro de la plantilla provocaremos un error. Esto suelen pasar por que este código utiliza también las llaves. La solución a este problema consiste en separar este código en archivos y utilizar el método estándar de HTML para su inclusión o la utilización de bloques {literal} {/literal} para agruparlos. Este bloque indica al motor de Smarty que no interprete el contenido del mismo.

Los comentarios son delimitados por {* y *}. Las variables son referenciadas con el signo de ( $ ) y las constantes con signo de numeral:

• { * foo * } <-- comentario de plantilla, no se muestra en HTML
• {$foo} <-- desplegando el valor de la variable
• {$foo[4]} <-- desplegando el quinto elemento del arreglo
• {$foo.bar} <-- mostrando el valor de la llave "bar"
• {$foo.$bar} <-- mostrando el valor de la llave correspondiente al valor de la variable "bar"
• {$foo->bar} <-- desplegando el valor de la propiedad bar (objeto)
• {$foo->bar()} <-- desplegando el valor que regresa la función "bar()"
• {#foo#} <-- mostrando el valor de la constante "foo"

Generalmente los valores de constantes son definidos en archivos de configuración almacenados en la carpeta /configs/ del directorio donde está trabajando Smarty y tienen una configuración especial. Su utilización es importante por muchos motivos, incluyendo texto en otros lenguajes o configuraciones de colores, frases cortas, etc. Para cargar un archivo de configuración dentro de la plantilla puede utilizarse la función: {config_load file="foo.conf"}

Dentro del archivo de configuración, la definición de las constantes puede ser:

• pageTitle = “This is mine”
• bodyBgColor = “#eeeeee”
• tableBorderSize = “3″
• tableBgColor = “#bbbbbb”
• rowBgColor = “#cccccc”

Funciones:

Cada etiqueta Smarty muestra una variable o utiliza algún tipo de función. Las funciones son procesadas y mostradas colocando atributos de la función entre delimitadores. Los atributos en las funciones son colocados al mismo formato que los atributos HTML:

{include file="header.tpl"}
{include file="header.tpl" attrib_name="attrib value"}
{include file=$includeFile}
{include file=#includeFile# title="Smarty is cool"}
{html_select_date display_days=yes}
<select name="company">
{html_options options=$choices selected=$selected}
</select> 

La variable reservada {$smarty}

Esta variable es de un caso especial dentro de la plantilla. Desde esta variable podemos acceder a objetos dentro de la plantilla, sentencias, bloques de instrucciones, variables y constantes de PHP, también proporciona un método para acceder a las constantes de archivos cargados y otras propiedades. Para mayor información, es recomendable leer el documento de ayuda de Smarty.

Modificadores de variables

Dentro de la plantilla podemos hacer modificaciones a las variables enviadas desde PHP. Smarty proporciona estos para trabajar dentro de la plantilla. Para aplicar un modificador, es necesario especificar el valor seguido por | (pipe) y el nombre del modificador. Si un modificador necesita parámetros estos siguen al nombre del modificador y son separados por : (dos puntos).

{* aplicar modificador a la variable *}
{$title|upper}
{* modificador con atributos *}
{$title|truncate:40:"..."} 

También es posible combinar modificadores. Simplemente basta con colocar el siguiente con la misma sintáxis; separados por |(pipe).

Conclusiones

Este tipo de herramientas facilitan mucho el trabajo a los desarrolladores, lo importante es obtener de ellos todo el potencial. Utilizando Smarty en nuestros proyectos nos será de mucho beneficio, al desarrollar con la herramienta podemos separar la lógica de programación de la presentación y además involucrar a los diseñadores dentro del proceso.

Las plantillas pueden incluir programación pero al estar vinculada casi por completo a la presentación es mucho más fácil de comprender para los diseñadores, porque no incluye elementos confusos. Además, el diseñador puede hacer los cambios que quiera sin depender del programador.

NOTA: los ejemplos incluidos en este artículo fueron extraídos del manual de referencia de Smarty.

Lecturas recomendadas:

• Smarty: razones para utilizar plantillas en mis proyectos
• ¿Qué es Smarty?

A muchos programadores se nos ha inculcado este concepto, solemos trabajar en grupos de profesionales conformados por desarrolladores y diseñadores gráficos. Luego, que el diseñador a elaborado su propuesta gráfica, su diseño pasa al departamento de desarrollo para que a partir del mismo se elabore la programación.

Muchos profesionales de Internet suelen dedicarse al desarrollo de sitios, otros al desarrollo de aplicaciones. Para ambos casos el diseño juega un papel muy importante. Los que se dedican a la elaboración de sitios web, en muchos de los casos utilizan herramientas de terceros como Joomla!, Drupal, WordPress (por mencionar algunos).

Estas herramientas de uso general suelen incluir un sistema de plantillas para manejar una diversidad mayor de diseños. Cada uno, utiliza un motor diferente que realiza su cometido. Lo importante es destacar que estas soluciones utilizan un sistema de plantillas o diseños para cambiar la cara del sitio que se esta administrando.

Por qué es importante utilizar un sistema de plantillas

La principal razón es que de esta manera ahorramos tiempo cuando depuramos la aplicación. Una mala práctica de desarrollo consiste en embeber código de programación junto con el diseño y la maquetación. La mayoría de lenguajes de programación permiten esta práctica. El utilizar plantillas es importante por muchas razones:

• Es más sencillo darle mantenimiento a un script que solo incluye programación.
• Dependiendo de nuestra programación, nuestra aplicación no depende del diseño y permite cambiarlo sin tener que hacer cambios dramáticos en la parte de programación.
• Ambos profesionales pueden dedicarse a su área de experiencia. Los programadores desarrollan y los diseñadores crean la vista de cara al usuario.

¿Qué es Smarty?

En el caso particular de programación en lenguaje PHP existen muchas soluciones para el manejo de plantillas. Smarty es un proyecto muy importante dentro del universo de paquetes desarrollados en PHP. Smarty es un motor de plantillas muy potentes y versátil con capacidades de expansión a través de submódulos, extensiones y funciones.

Los desarrolladores de Smarty supieron implementar un diseño de arquitectura de programación basado en el concepto de que una aplicación debe separar correctamente su lógica de programación de su diseño. Smarty incorpora una sistema de patrones de sintáxis para que dentro de la plantilla podamos incluir manejo y manipulación de variables; es decir dentro de una plantilla de Smarty puede hacerse programación.

Es importante mencionar que muchos proyectos importantes utilizan Smarty para el manejo de plantillas. Además, hay implementaciones de Smarty en otros lenguajes de programación como el caso de Canny desarrollado en Ruby y que puede interpretar las plantillas de Smarty.

Aparte de las ventajas antes mencionadas, Smarty es ideal para que los encargados del diseño puedan involucrase también en el desarrollo. Al separar la programación y diseño, los diseñadores pueden participar lo cual permite que el proceso del proyecto sea mucho más rápido a la vez que da al diseñador un panorama mejor en cuanto a su arquitectura.

Empezando a utilizar Smarty

En su modo más sencillo, Smarty recibe variables para su impresión dentro de la plantilla. Smarty trabaja a través de un objeto clase, las funciones más utilizadas serán:

$smarty->assign("ID_EN_PLANTILA", "VARIABLE"):  agrega la variable dentro del indice de variables de Smarty.
$smarty->display("NOMBRE_PLANTILLA"): despliegua y procesa la plantilla

Ejemplo de inicialización de la variable de Smarty:

# Incluye la clase de Smarty
require "Smarty/libs/Smarty.class.php";                  

# Inicia el objeto
$smarty = new Smarty(); 

# Indica los directorios
$smarty->template_dir = "templates/";
$smarty->compile_dir  = "compiles/";
$smarty->caching      = false;
$smarty->cache_dir    = "cache/";
$smarty->config_dir   = "configs/"; 

# Manda variables a la plantilla
$smarty->assign("MY"        , $_SESSION["my"]);
$smarty->assign(”TITLE_PAGE”, “Smarty: Template Engine”); 

# Indica la plantilla
$smarty->assign(”template.tpl”); 

Conceptos para la creación de plantillas en Smarty

En el ejemplo anterior se ilustra el método de inicialización del objeto de Smarty, la cual es bastante sencilla. Ahora bien, Smarty utiliza principalmente cuatro directorios:

template_dir: El directorio donde se almacenan las plantillas.

compile_dir: el directorio donde se almacenan los archivos compilados. Este directorio debe tener permisos de lectura y escritura en el servidor. Smarty utiliza un sistema bastante peculiar para compilar las plantillas. La clase lee el archivo de la plantilla y cuando la compila, deja indicado dentro del archivo la fecha de generación. Cuando se le vuelve a pasar al objeto que se procese la página, el motor verifica esa fecha y si no ha sufrido cambios, no lo procesa. Esto es importante, por que de esta manera no compila algo ya listo para ser utilizado y ahorra tiempo en el servidor.

config_dir: ya se menciono que Smarty tiene una sintáxis propia. Los archivos de configuración son un agregado del sistema. El objetivo es que dentro de estos se almacenen valores de configuración que no cambian pero que es importante que permanezcan como valores de constante. Dentro de estos archivos pueden clasificarse las constantes en secciones y dentro del TPL pueden referenciarse de un modo particular.

Conceptos:

Una plantilla puede incluir varias plantillas con lo cual se consigue una estructura de árbol, independiente del script. Smarty trabaja con todos los tipos de datos nativos en PHP. Otras implementaciones en otros lenguajes podrían variar en este funcionamiento.

La sintaxis de Smarty es muy similar a la de PHP, aunque con modificaciones. Por ejemplo las instrucciones se delimitan con llaves ( { } ) , pueden agregarse comentarios dentro de la plantilla ( { * * } ) , existen las estructuras de control IF y FOREACH (para el manejo de variables tipo Array) y otras variaciones de estructuras de control. Las variables se representan con el signo de ( $ ).

Existen funciones para manipulación de datos, generalmente suelen invocarse después de la referencia a la variable, a través del carácter ( | ), y los parámetros después de ( : ). Ejemplo: {$MY->username[strlen}

Consejos:

Aunque puede incluirse código de PHP dentro de la plantilla, esta práctica no es recomendada. Una buena práctica de programación consiste en enviar variables en arreglos sin ningún tratamiento en HTML para que la plantilla proceda a tratarla. Como se describió anteriormente, puede incluirse plantillas dentro de plantillas. Esto puede resultan beneficioso para optimizar aún más la plantilla, incluyendo porciones de plantilla en varios archivos.

Smarty es una gran solución de motor de plantillas. Contiene una gran arquitectura que puede ser ampliada según nuestras necesidades. Esta ha sido solo una pequeña introducción al paquete. En próximos artículos describiremos a mayor detalle cada una de las características dentro del sistema para que obtengamos el máximo desempeño del mismo.

Finalizamos con el ciclo de artículos inspirados en el modelo L5 constituidos por una introducción sobre Desarrollo multinivel para aplicaciones basadas en el web, Modelado de datos e implementación de la base de datos (Primer Nivel: L5), Lógica de programación (Segundo Nivel:L5), Estructura de contenidos (Tercer Nivel:L5), Diseño Gráfico (Cuarto Nivel: L5) y terminamos con la Maquetación de la aplicación.

Nuestro usuario final estará en contacto con nuestra aplicación através del navegador y las tecnologías que soporta son XHTML, CSS y JavaScript, principalmente. Para muchos de los diseñadores y programadores esta parte envuelve un cierto grado de expectación.

Al existir tantas alternativas de navegadores, debemos tener especial cuidado en que nuestro sitio sea “renderizado” por la mayoría de ellos. El que nuestro sitio este accesible para la mayoría es importante; que este accesible para todos es trascendental (en este aspecto, me refiero a lo estupendo que es, que se vea bien en todos).

Las diferencias en el modo de trabajo de cada uno hace que para muchos profesionales de integración y maquetación, sea un completo dolor de cabeza, el tratar de dar soporte a cada uno, con sus diferencias. Pero debemos de recordar que nuestra misión es que nuestro proyecto pueda ser visto por nuestros usuarios, sin importar su sistema operativo, navegador y configuraciones especiales.

Es perfectamente comprensible que creamos que existe mucha dificultad en lograr el soporte para todos. Esta será una labor constante; reparando y probando el desempeño del sitio en diversas configuraciones poco a poco y corrigiendo los fallos que puedan existir.

Maquetar para múltiples dispositivos

Este tema puede llegar a ser un tanto controversial. ¿Por qué deberíamos preparar nuestro sitio para que sea visto en diferentes dispositivos? ¿Vale la pena hacer un esfuerzo en que mi proyecto pueda verse en un computador, un teléfono o mi iPod?. En mi opinión la respuesta es afirmativa, según mis perspectivas de proyecto.

El maquetar para más de un explorador ya es un reto en si; el hacerlo para teléfonos con acceso a Internet de alta velocidad, hace que mi aplicación sea y se vea más potente. Pero, ¿Cómo puede maquetarse para múltiples dispositivos?.

La respuesta es usar plantillas y dotar a la aplicación de un sistema de detección del explorador y/o dispositivo. Por ello, es importante que si vamos a realizar una aplicación bajo esta estos paradigmas, las salidas deben ser en un formato estándar, con el cual, al cambiar entre distintos temas, no estemos redundando en programación, duplicando scripts, etc.

Existen en la actualidad, varios sistemas de manejo de plantillas. Para los desarrolladores en PHP, el más conocido es Smarty. Este sistema de plantillas trabaja bajo una estupenda metodología de separación del contenido del diseño, dotando al archivo de la plantilla de un conjunto de etiquetas, que le permite agregar programación y trabajando con las variables enviadas desde el lenguaje.

Existen otros sistemas de plantillas en diferentes lenguajes. Muchos frameworks ya cuentan con un sistema de plantillas diseñado para aprovechar las características del lenguaje y hacer más fácil el crear temas y hacer la maquetación del sitio.

Yo doy un voto a la forma en que trabaja Smarty, también existe un sistema de plantillas bajo Ruby que interpreta el formato de archivo de Smarty. Una idea en cuanto al uso de varias plantillas es que se concentra en un archivo la información que va a salir en determinado momento (podría ser un archivo por salida o por proporción de contenido a volcar) y que el archivo que contiene la salida pueda determinar el tema que hay que desplegar.

Cuando diseñamos un tema para el navegador y posteriormente lo maquetamos debemos tomar en cuenta varios aspectos:

• Utilizar con cuidado los tamaños de los elementos. En la actualidad, el estándar de navegación en tamaño de resolución de pantalla es 1024×768. Muchos desarrolladores cuentan con monitores con una capacitad mayor. Es recomendable que maquetemos a esta resolución estándar y que nuestro sitio se vea con un diseño adaptativo. Algunos expertos recomiendan el uso de valores em en vez de valores en pixeles para que el texto se adapta al tamaño de la resolución.
• Cuando maquetemos, hagamoslo según los estándares. La utilización de estándares asegurará que el navegador tratará el documento de una mejor manera. Pero no nos asegura un 100% de soporte.

Maquetación para una actualización

El ejemplo más claro en cuanto al factor de diseño y maquetación es el cambio de paradigma del modelo convencional basado en una estructura de tablas a la actual, basada en contenedores fluidos y div’s.

El formato HTML como tal va camino a una profunda reestructuración y actualización del modelo (HTML 5 y XHTML 2), dejando fuera ciertos elementos considerados obsoletos e introduciendo otros nuevos, llamados etiquetas semánticas. El desarrollo de cualquier proyecto debe contemplar la actualización para el futuro, tanto del diseño como de la parte estructural del lenguaje que lo sustenta. Esto nos dice que no debemos dejar abandonado el proyecto.

Además, también debemos contemplar los cambios que se producen a nivel de exploradores. Lo que funcionaba perfectamente en la versión anterior del programa, pueda que en la nueva funcione de manera distinta.

Por ejemplo: la versión 6 o anterior de Internet Explorer no contaba con soporte nativo para el despliegue de imágenes en formato PNG; sino a través de un filtro, podría lograrse el tan esperado efecto de transparencia.

Esto causo que por largo tiempo, las páginas HTML no pudieran incluir imágenes en este formato. La solución a este caso fue el uso de tecnologías como Flash (que incluía otros efectos). Otro ejemplo es el tan sonado caso Microsoft-EOLAS, por el cual Microsoft tendrá que modificar el comportamiento de los objetos embebidos como QuickTime, Java Applets, Flash, etc. Incrustandoles un marco de activación.

Todos estos cambios que se vienen en nuevas versiones hacen que la experiencia del usuario cambie. Debemos estar atentos a ellos para solucionarlos. Como conclusión a esta sección del artículo puedo inferir que preparar la maquetación para una actualización simplemente nos ayudará a mejorar, agilizar y optimizar los cambios futuros que debamos desarrollar.

Separación completa del esquema HTML, CSS y JavaScript

Al fin llegamos a la parte práctica del artículo. ¿Por qué separar la maquetación en HTML, CSS y JavaScript?. La respuesta es bastante obvia. Para mejorar el rendimiento. Los beneficios son bastantes, igual que los retos:

• HTML proporciona la estructura
• CSS define el diseño de los elementos
• JavaScript le da una funcionabilidad adicional

Al separar la presentación al usuario estamos:

• Mejorando el rendimiento dado que consumimos menos ancho de banda en transferencia.
• Reutilizando código, diseño, etc.
• Agilizando el proceso de actualización. El tiempo que nos lleve realizar la actualización es directamente proporcional al número de archivos que debamos cambiar para realizar dicha actualización.

Descargar el ejemplo.

En el modelo L5 la maquetación es la fase última de desarrollo del proyecto. Hasta aquí hemos realizado un gran esfuerzo para construir una aplicación que cumpla con las expectativas de nuestro cliente y usuarios, a la vez que sea robusta y este bien estructurada.

Hemos aplicado una metodología de desarrollo clara, sencilla y basada en muchos conceptos nuevos y otros que posiblemente ya hemos escuchar, pero que ya enfocados sobre el modelo son simples de entender y aplicar.

El propósito fundamental de esta guía fue proponer el modelo L5 como un esquema de separación de las capas de desarrollo de proyectos para Internet. La oportunidad está abierta para aquellos que sepan llevar a cabo proyectos importantes, sostenibles y estables.

Siguiendo con el ciclo de artículos inspirados en el modelo L5 constituidos por una introducción sobre Desarrollo multinivel para aplicaciones basadas en el web, Modelado de datos e implementación de la base de datos (Primer Nivel: L5), Lógica de programación (Segundo Nivel:L5), Estructura de contenidos (Tercer Nivel:L5) y ahora abordaré el Cuarto Nivel: L5 dedicado al diseño gráfico.

Ahora, parece ser que la tendencia de desarrollo esta muy ligada a lo casual, con colores pastel, letras grandes, muy al estilo tipográfico y de revistas. Es increíble como los gustos han cambiado en tan poco tiempo; y seguirán cambiando en lo futuro.

Al parecer en Internet la tendencias de la utilización de gráficos estáticos está volviendo con un toque moderno y suelto. Si estamos dedicados al desarrollo y seguimiento de un proyecto publicado en Internet, una aplicación para clientes y todo aquel proyecto que esté en comunicación con usuarios fuera del ámbito administrativo, estar atento a las tendencias de diseño, es muy importante:

• Indica a nuestros usuarios que la aplicación está siendo supervisada y no es un proyecto que se ha descuidado o abandonado.
• Ayuda a mejorar la experiencia del usuario y llegar a un grado mayor de usabilidad.

Podría también decirse que ayuda a que el proyecto se vea más fresco e incluso a la moda en diseño, aunque sea una aplicación con bastante recorrido en Internet.

Expresando el contenido de una manera gráfica

Ahora, dejando un poco de lado la parte de las tendencias y centrándonos en la parte tal cual de la elaboración de diseño, debemos siempre recordar que sea cual sea nuestra inspiración de diseño, finalmente este deberá adaptarse al contenido real de la página y al público que este enfocado.

Los diseñadores deberían trabajar conjuntamente con los encargados del contenido y los profesionales encargados de la maquetación final del sitio o aplicación. Esto con el objetivo de que el diseñador sepa del contenido que debe incluirse en el diseño y que conozca las limitaciones del medio de Internet.

Un error que suele cometerse con bastante regularidad en el desarrollo para Internet es que los diseñadores suelen ser los primeros en el orden de elaboración de proyectos. Generalmente los encargados del diseño suelen presentar sus propuestas de diseño antes de lo que realmente se deberían de presentar en detrimento de los encargados de la maquetación del sitio.

El resultado es de esperarse: diseños completamente fuera de la realidad de Internet, muy difíciles de plasmar en HTML; a veces con mucho contenido dinámico, animaciones y distractores. Por suerte, muchos profesionales del diseño en la actualidad, ya no suelen cometer estas faltas.

Aquí sería conveniente que los diseñadores trabajen conjuntamente con el resto del equipo asignado para el proyecto, para tomar ideas de ellos y cuando haya un consenso de los diseños propuestos, mostrárselos al cliente para su aprobación.

Un buen diseño se acoplará al contenido del sitio y le dará la marca distintiva de originalidad que debe estar presente en todo proyecto para Internet. Los diseños simples siempre serán una buena opción, aunque para ciertos casos es interesante probar elementos nuevos.

La regla general será hacer diseños agradables en donde la distribución del contenido este en el ángulo de la página donde cumpla su cometido fundamental.

Factores de diseño para un proyecto dinámico y escalable

Lo fundamental en todo diseño para Internet es la sencillez, es decir que no este cargado con elementos que distraigan o estén fuera de lugar, eso es elemental. Las ventajas se centran en que un diseño sencillo es más apreciado que un diseño complejo con tantos detalles.

Además, los beneficios que también implica incluyen un menor consumo de ancho de banda en el producto final. Como en todo lo anteriormente dicho, el uso de Flash debería estar restringido al mínimo o para salir de la monotonía de las imágenes GIF y que nunca se coloque información o contenido dentro; en especial si este contenido ayuda al posicionamiento del sitio en motores de búsqueda.

También es importante tomar en cuenta la usabilidad: la buena distribución del contenido, la inclusión de guías para localizar de manera fácil lo que el navegante está buscando, el uso de estándares de diseño como la inclusión de un vínculo en el logotipo para ir a la página de inicio o la simple presencia del famoso puntero de la “manita” para señalar vínculos. Otra sugerencia es “ponerse del lado del usuario”.

Pienso que un diseño cumple con su misión cuando un navegante nuevo (entiéndase que nunca ha entrado a nuestro sitio con anterioridad) puede encontrar lo que busca en el menor tiempo requerido por que los elementos gráficos simplemente le guían, que gusta del diseño y que se toma el tiempo de colocarlo como marcador.

El diseño siempre será fundamental en todo proyecto para Internet. Un proyecto sin un buen diseño simplemente no servirá por que no hay atractivo en usarlo. Y un diseño sin un buen contenido simplemente será una imagen bonita. La tarea es trabajar conjuntamente y dejar que los profesionales trabajen en su área, siempre listos a escuchar a sus compañeros de equipo con los que tienen que trabajar para lograr el mejor resultado.

Cuando propuse L5 como un modelo de desarrollo, deje como cuarto nivel al diseño de la interfaz, porque muchos profesionales de Internet envueltos en el desarrollo pueden tener mucha experiencia en todas las áreas.

Pero el diseño es un área más con la que contará nuestra aplicación y solamente puede ser elaborado por profesionales con la sensibilidad única que se necesita para darle a nuestro proyecto ese toque de genialidad gráfica y artística.

Las imágenes proporcionadas en este artículo fueron extraídas del artículo: Inspiration Package: 60+ Usable & Elegant Designs.

El contenido que se maneja dentro de la aplicación es fundamental para que los usuarios consideren atractivo ingresar a él. Es por ello que en el Modelo L5 es un aspecto que debe ser profundamente evaluado.

La importancia del Contenido en el Modelo L5:

En el modelo L5 el contenido es el punto de unión entre la tecnología del Servidor y las tecnologías del cliente. Muchas veces, para nuestros usuarios no importará la programación que haya sido envuelta en la generación del contenido, lo importante son los resultados.

Al dividir el modelo en cinco fases, agregué una especial, para hablar acerca del contenido. El contenido que hemos extraído desde nuestra Base de Datos y hemos procesado dentro de la Lógica de Programación, debe ser estructurado de una manera especial, para poder ser presentado al usuario final de la manera correcta.

El contenido, no debe ser estimado como el simple producto de nuestra labor, dentro de nuestra aplicación sino como el final de la misma. Cuando hablo de la finalidad, me refiero a que es el valor y utilidad que le da a nuestra aplicación.

Por qué trabajar con un modelo estándar basado en XML

XML es un formato de documento, creado y pensado para la estructuración y el modelado de información. No es una tecnología como PHP ó Ruby.

XML simplifica en muchos casos la manipulación de la información dentro de los medios de almacenamiento y recuperación. Todos sabemos que se basa en la definición de etiquetas y su estructuración a través de un modelo jerárquico.

Su uso en la generación del contenido que debemos presentar indicaría que no importará que tecnología apoyo su formación. Siempre y cuando el formato del documento XML generado sea el mismo la aplicación podrá seguir operando sin ningún cambio aparente.

Existen diversas tecnologías derivadas de XML como los formatos SVG, MathML, RDF, XBL; cada una con una función específica, que nos ayudará en determinadas necesidades. Hay diferentes razones, por las que el uso de XML sea valioso en nuestros proyectos:

• Es un estándar.
• Independiza la presentación del contenido de la tecnología empleada para generarlo, es decir, independiza la tecnología de servidor, de la tecnología del explorador.
• Su uso nos permitirá hacer que módulos desarrollados en otros lenguajes puedan comunicarse con otros módulos, sin necesidad de hacer configuraciones adicionales.
• Se adapta a nuestras necesidades, un documento XML, puede ser estructurado de diversas maneras y ampliado en su estructura, para que puedan ser agregados nuestros registros de campos y valores, sin que esto comprometa el uso que le da otros módulos que operaban con esa estructura antes de su cambio.

Por tanto, es recomendable el uso de XML dentro de L5, su implementación en cualquier lenguaje de scripting es bastante sencilla, dada la multitud de módulos o parsers que existen en la actualidad para muchas plataformas.

Formateo del documento XML

Ahora bien, el siguiente paso sería el parseo del documento XML anteriormente generado. Este puede ser realizado por un lenguaje de scripting (que podría ser el mismo empleado para generar el XML, con el agravante que para muchos esto podría resultar en una redundancia y complejidad, dentro del proceso) o por el lenguaje del explorador a través de XSL o el mismo JavaScript según sea la necesidad y el objeto del formato del documento.

En la primera opción: el parseo y recuperación de la información, en un formato nativo para el lenguaje de scripting, la razón fundamental es principalmente por la problemática que puede operar en sitios de Internet.

La optimización para motores de búsqueda hace necesario que las páginas sean servidas como tal, en cuanto a su contenido que es el que interesa al motor de búsqueda. Si utilizásemos XSL para transformar el documento XML el motor de búsqueda no podría interpretar correctamente la página y esto sería en detrimento del posicionamiento del sitio.

Ahora bien la optimización en cuanto al uso de XSL podría ser utilizada en administradores o en herramientas web, que no requieran posicionamiento. Pero, debemos de tener en cuenta el soporte de esto en navegadores. En la actualidad, el mejor soporte es logrado en productos de la suite Mozilla. Pero también cuenta con el mismo soporte Internet Explorer, Opera y Safari.

Optimización para múltiples dispositivos

Otra ventaja importante es que cuanto separamos el contenido del diseño e incluso del HTML logramos que con implementaciones, el contenido se adapte a diversidad de dispositivos. Si hablamos de navegadores también podemos incluir el uso de plantillas, diseños, skins y templates. Una idea sería que un sitio sea personalizable en este aspecto.

Ahora, si nos referimos a múltiples dispositivos, estamos indicando que nuestro sitio este disponible no solo vía un ordenador, sino a través de otros dispositivos con acceso a Internet, unidades móviles, teléfonos, etc.

Las nuevas tendencias muestran que Internet cobrará mayor auge y que el acceso no se hará solamente por computadores sino dispositivos, como teléfonos celulares, unidades móviles y cualquier dispositivo con acceso a Internet de alta velocidad vía Wi-Fi.

Un ejemplo claro, son las unidades iPhone y el nuevo iPod Touch, otras como el Blackberry y otros dispositivos. Dependiendo del nivel de alcance y los servicios que quiera ofrecer nuestra aplicación, así podremos realizar soporte para múltiples dispositivos.

Tomando en cuenta este enunciado, sería fantástico que podamos hacer que nuestro proyecto, pueda verse en más de una plataforma distinta al ordenador. Ese es el deseo de muchos entusiastas y de la propia W3C que busca que el Internet y la World Wide Web, sea accesible para todos, sin importar el dispositivo que utilicen para estar en línea.

El separar el contenido nos ayudará a cubrir esta necesidad para dar a nuestros usuarios una mayor calidad de experiencia bajo nuestros servicios.

El esquema de contenido define la presentación

Recapitulando, decimos que el contenido, manda sobre el diseño. El diseño se adapta al contenido, el esquema de contenido define la presentación, utilizando XML podemos generar dicho esquema, dependiendo de cada uno de los contenidos que queramos desplegar. Se adaptará a cada necesidad y el contenido entrará a formar parte del diseño a través de la maquetación.

Pero recordemos: el formato XML no es la única opción que podemos emplear, también existe otros lenguajes de marcado como JSON y YAML. Obviamente, existe muchos más, pero su uso dependerá si cumple nuestras necesidades de la mejor forma.

Descargar ejemplo

Lecturas relacionadas:

• Desarrollo multinivel para aplicaciones basadas en el web
• Modelado de datos e implementación de la base de datos (Primer Nivel: L5)
• Lógica de programación (Segundo Nivel:L5)

En los inicios de Internet, la programación se limitaba a presentar documentos estáticos. Conforme fue evolucionando, surgieron las tecnologías que actualmente conocemos con Lenguajes de Scripting.

En la actualidad, los lenguajes dominantes son PHP y ASP.Net les siguen de manera rezagada Pearl y JSP. Y como tecnologías que están tomando impulso tenemos Ruby (con su framework Rails) y Python (en este punto, creo que la principal razón de que Python esté tomando impulso, es por el uso intensivo que Google le está dando).

Realmente, no interesa en un 100% que tipo de t