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.

Juan Manuel Lemus para Maestros del Web.
Agrega tu comentario | Enlace permanente al artículo

Síguenos en: @maestros | Fan page

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.

Juan Manuel Lemus para Maestros del Web.
Agrega tu comentario | Enlace permanente al artículo

Síguenos en: @maestros | Fan page

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.

Juan Manuel Lemus para Maestros del Web.
Agrega tu comentario | Enlace permanente al artículo

Síguenos en: @maestros | Fan page

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.

Juan Manuel Lemus para Maestros del Web.
Agrega tu comentario | Enlace permanente al artículo

Síguenos en: @maestros | Fan page

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

Juan Manuel Lemus para Maestros del Web.
Agrega tu comentario | Enlace permanente al artículo

Síguenos en: @maestros | Fan page

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.

Juan Manuel Lemus para Maestros del Web.
Agrega tu comentario | Enlace permanente al artículo

Síguenos en: @maestros | Fan page

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.

Juan Manuel Lemus para Maestros del Web.
Agrega tu comentario | Enlace permanente al artículo

Síguenos en: @maestros | Fan page

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.

Juan Manuel Lemus para Maestros del Web.
Agrega tu comentario | Enlace permanente al artículo

Síguenos en: @maestros | Fan page

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.

Juan Manuel Lemus para Maestros del Web.
Agrega tu comentario | Enlace permanente al artículo

Síguenos en: @maestros | Fan page

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?

Juan Manuel Lemus para Maestros del Web.
Agrega tu comentario | Enlace permanente al artículo

Síguenos en: @maestros | Fan page

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.

Juan Manuel Lemus para Maestros del Web.
Agrega tu comentario | Enlace permanente al artículo

Síguenos en: @maestros | Fan page

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.

Juan Manuel Lemus para Maestros del Web.
Agrega tu comentario | Enlace permanente al artículo

Síguenos en: @maestros | Fan page

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.

Juan Manuel Lemus para Maestros del Web.
Agrega tu comentario | Enlace permanente al artículo

Síguenos en: @maestros | Fan page

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)

Juan Manuel Lemus para Maestros del Web.
Agrega tu comentario | Enlace permanente al artículo

Síguenos en: @maestros | Fan page

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 tecnología estemos utilizando. Cada una tiene ventajas y desventajas que nos permite crear nuestros proyectos. En un mundo tan competitivo, no podemos simplemente pensar que utilizando la tecnología del momento, llegaremos a tener mayor éxito.

Las tecnologías cambian y son sustituidas. Nuestros proyectos subsistirán no por el lenguaje o tecnología que utilicemos, sino por la misma esencia del proyecto y como haya sido pensado y desarrollado.

Desarrollo descentralizado

Primero debemos de tener el concepto de programación modular. Sea que estemos desarrollando para una aplicación nativa o para Internet. Pero, centrándonos en el caso de la programación para Internet, al menos deben intervenir 5 tecnologías (SGBD, Scripting, HTML, CSS y JavaScript).

Cuando hablamos de desarrollo descentralizado, en el modelo L5 no nos referimos a estas separaciones (que elementalmente son los cinco nivel del método), nos referimos, en el caso del nivel de Lógica de Programación, a la separación dentro de la lógica, en clases, procedimientos y funciones de una manera correcta.

El desarrollo descentralizado no consiste simplemente en hacer esa separación, de hecho, muchas partes del desarrollo deben estar separadas en componentes, a través de clases bien estructuradas, aprovechando las capacidades del lenguaje que utilizamos. Siempre quiero repetir esto, por que creo que es importante.

No se trata solamente de hacer una aplicación, se trata de que nuestro proyecto llegue a ser un referente en todo sentido. La gran característica de aplicaciones o módulos como Smarty, ADODB, entre otros, es que piensan en la reutilización. Hacer algo que pueda ser aplicado en muchos otros proyectos.

Lo realmente interesante de crear aplicaciones con componentes de este tipo, es que podemos ir creando estructuras personalizables que nos permitan extender su uso; con lo cual, vamos ganando experiencia y nuestro componente se va haciendo cada vez más potente.

Por ejemplo, consideremos un componente del lado de la programación, que nos permita crear backups periódicos de nuestra base de datos. Con una buena combinación de programación e incluso un diseño de interfaz, este módulo nos permitiría agregar una nueva funcionalidad a nuestro proyecto. A la vez que estamos descentralizando funciones, estamos haciendo componentes reutilizables.

¿Por qué sitios como Google o Yahoo pueden ofrecer tan buenos servicios?

Sin duda, es una idea con una gran dimensión de respuestas. Puede que cuenten con los mejores equipos de desarrolladores. Pero parte de su éxito consiste en utilizar una buena técnica de programación que combina componentes descentralizados y reutilizables.

Programando entre tecnologías

Si tomamos como base el caso de Google, podemos conocer que su desarrrollo principal funciona sobre el lenguaje Python, utiliza módulos en otros lenguajes como C para sus funciones. Todos sabemos de la compra que Google hace a otras empresas que utilizan diferentes tecnologías. ¿Cómo es que Google puede controlar todos estos servicios y combinarlos con éxito?.

Los lenguajes por naturaleza, han sido desarrollados para interactuar con componentes desarrollados para si mismos. No permiten la utilización de otro código de manera nativa, sino a través de aplicaciones que son intermediarias entre el lenguaje principal y el huesped.

Además de este tipo de desarrollo, que requiere una configuración más avanzada dentro del mismo servidor, existen otros métodos como los famosos Web Services que permite la comunicación entre dos o más servidores con tecnologías distintas o la utilización de tecnologías estándar como XML, JSON o YAML, cuyos intérpretes han sido desarrollados para muchas plataformas y lenguajes.

PHP + ASP.Net + Ruby

Cómo optimizar y desarrollar más fácilmente utilizando múltiples tecnologías al mismo tiempo. Desde el artículo de introducción, hice mención de que una de las justificaciones para desarrollar bajo el concepto de CROSS-SCRIPTING era que podíamos utilizar lo mejor de cada tecnología para realizar una aplicación basada en Internet.

Debo aclarar que la utilización de varias tecnologías dentro de un proyecto, no debe ser una obligación para desarrollar bajo este método de desarrollo. Si nuestro proyecto no lo requiere, no hay ningún inconveniente en no acatar este punto.

Otra justificación, es que así, vamos independizando los módulos de la aplicación. Cada lenguaje tiene un grado de actualización diferente. También al desarrollar de esta manera podemos simplificar procesos. Por ejemplo, una de las ventajas principales del lenguaje PHP es su versatilidad para manejar variables y que los tipos de datos no son estrictos.

En adición a esto, ASP.Net, está muy integrado con la plataforma .Net de Microsoft, que integra muchas funciones y procedimientos muy potentes. Y si comparamos Ruby, podemos comentar que tiene un gran soporte para la programación orientada a objetos. Y así sucesivamente podemos enumerar muchas ventajas, que al combinarlas, nos permiten integran una aplicación realmente potente.

En la actualidad, es posible integrar todos los servicios en un solo Servidor, generalmente Apache. En los últimos días he leído acerca de la posibilidad de utilizar ASP.Net directamente en Apache. Proyecto como Mono que también permiten programar en ASP.Net bajo otras plataformas como Mac OS X o Linux.

Creo que la mejor manera de integrar cualquier tecnología es haciendo que trabaje bajo el enunciado de un módulo completo, y que se comunique a través de lenguajes estándar. La optimización se hará dentro del mismo entorno de programación.

Comunicación entre la BD y la Tecnología de Scripting: Vistas y Procedimientos

Un ejemplo de comunicación entre dos tecnologías diferentes. Pero, en este caso, resulta más sencillo su comunicación, por la gran diversidad de controladores que existen que permiten comunicarnos de cualquier plataforma de desarrollo de scripting a cualquier Gestor de Base de Datos.

Ahora bien, depende mucho el tipo de comunicación y el grado de privilegios que tenga nuestra aplicación sobre la Base de Datos sobre la que va actuar. Generalmente, tendremos el control total sobre la misma, a excepción de sistemas con una base de datos ya existente, siendo nuestro programa un módulo de extensión. Pero en primer caso, la utilización de consultas directas, no es una buena opción.

El SGBD, recibe instrucciones, generalmente en lenguaje SQL, que luego interpreta y ejecuta. En Base de datos pequeñas o aun en desarrollo, la fracción de segundos de diferencia es casi imperceptible, pero a media que vamos creciendo dentro de la base de datos de registros, la manipulación de esos datos es más lenta. En aplicaciones críticas, ese intervalo puede llegar a ser crucial.

El SGBD optimizará las consultas, pero una mejor manera de hacer que el sistema sea cada vez mejor, es utilizar vistas y procedimientos. Las vistas, son muy parecidas a las consultas comunes de tipo SELECT. Mucho comentan que su existencia, emula a una tabla más dentro de la base de datos.

La principal ventaja es que permite combinar resultados de varias tablas, con lo cual la obtención de los datos es más rápida. Otra ventaja de su utilización, es que en cuanto a los niveles de seguridad, el utilizar una vista es mucho mejor, porque para los usuarios que hacen la consulta, la vista representa una tabla y los campos parecen estar dentro de la misma entidad.

Además, dependiendo del gestor, puede que exista el concepto de Vista de una Vista, en que agrupamos aún más dichos valores, generalmente, por que estamos utilizando varias vistas que utilicen una misma estructura de valores de registros padre comunes.

En cuanto a los procedimientos, son importantes, por que su utilización, también permite un mayor grado de velocidad y seguridad al enviar los valores de los parámetros, permiten ejecutar más de una instrucción o consulta, etc. La comunicación a la base de datos, debe hacerse de igual manera de con cualquier método tradicional.

Posiblemente si así pudiese implementarse, la utilización de un archivo en formato estándar, podría ayudar, para centralizar esas consultas a los procedimientos y vistas, en el formato que más se ajuste (a mi parecer en este punto, XML).

# XMl
<?xml version = "1.0" ?>
<database engine = "mysql" version = "5.0">
      <section id =  "views">
            <query id = "90TY67SE">
                  SELECT * FROM `_userslist`
                    WHERE `username` = '%username%'
            </query>
      </section>
</database>
# PHP
$user = str_replace('%username%', 'maestrosdelweb',
                              getquery("90TY67SE"));

Generación del Esquema de Modelo XML

Antes de iniciar con la guía, estaba convencido que la mejor tecnología de vinculación para el modelo era XML. He leído arduamente respecto a este tópico, y aunque aun creo que una de las mejores opciones es XML.

El motivo de mi cambio es que aunque XML es muy bueno para describir datos, existen otras tecnologías para describirlos de igual manera, de una mejor manera, siempre adaptada al propósito de lo que se quiera representar.

En la actualidad, tecnologías como JSON o YAML están tomando auge en el área de intercambio de la información. Estos tiene objetivos específicos, pero su mayor ventaja es que describen la información más HUMAN-FRIENDLY, lo cual les proporciona un valor añadido.

Un claro ejemplo de ello se ilustra en el siguiente cuadro:

# En XML
<?xml version = "1.0"?>
<article name = "L5">
      <chapter number = "1" title = "Definición del Modelo Multinivel">
            <subtitle>Ventajas</subtitle>
            <subtitle>Desventajas</subtitle>
            <subtitle>Oportunidades</subtitle>
            <subtitle>Retos</subtitle>
      </chapter>
</article>
# En YAML
article: L5
chapter:
   - number: 1
   - title: Definición del Modelo Multinivel
  - subtitles: (Ventajas, Desventajas, Oportunidades, Retos)

Lo que si es importante de mencionar es que sea cual sea la tecnología a utilizar, el modelo sugiere que la salida, nunca sea en formato HTML/XHTML y otro propio de las tecnologías utilizadas en los siguientes niveles. Este punto es muy importante y es la base para la implementación del siguiente nivel.
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)

Juan Manuel Lemus para Maestros del Web.
Agrega tu comentario | Enlace permanente al artículo

Síguenos en: @maestros | Fan page

El modelado de datos es una técnica independiente de la implementación a la base de datos. Esto es importante, porque la metodología L5, siempre busca que se saque el máximo provecho de diversas herramientas. En particular, el esquema final y su implementación pueden sufrir cambios sin afectar de manera drástica la Lógica de Programación.

Uno de los puntos importantes que se deben indicar es que el modelado de los datos, debe ser llevado como una guía general. Para los profesionales expertos, esto implica el desarrollo de los Diagramas de Entidades y del Modelo Entidad-Relación. Independientemente de la metodología a utilizar, esta herramienta siempre será importante, para entender las relaciones entre las diversas entidades en la Base de Datos.

Cómo definir el esquema de la Base de Datos

Cuando definimos el Esquema de la Base de Datos estamos implementando en el lenguaje SQL del SGBD, el esquema de Modelado de Datos, anteriormente mencionado. Es preciso notar que se define “en el lenguaje SQL del SGBD”, este punto es importante que sea ampliado. Todos los SGBD, tienen diferencias finales en cuanto a la sintaxis que se maneja.

Sabemos que SQL es uno solo y que por eso es estándar, pero las diferentes distribuciones lo han implementado con ciertas variaciones. Están variaciones, son una de las causas en que el modelo de desarrollo, ha separado el Modelado de los Datos, con la Lógica de Programación.

El esquema de la Base de Datos, debe a mi parecer ser definido en el lenguaje SQL de nuestro Sistema Gestor de Base de Datos. La razón es básicamente sencilla: es más portable. Si lo hiciésemos en una aplicación nativa para un sistema operativo en especial y tratáramos de implementarlo directamente en otro sistema, podríamos llegar a tener complicaciones.

Es importante destacar, que no se trata de realizar todas las instrucciones SQL, en herramientas como Bloc de Notas. Muchas herramientas que podamos utilizar, nos permitirán exportar nuestra implementación a un archivo, que contendrá la sintaxis SQL. Además, si que sería destacable que como Administradores Generales de la Base de Datos, conociésemos de la sintaxis misma del lenguaje.

No es imperante que seamos unos gurus de la plataforma, pero siempre es importante que conozcamos los fundamentos. Muchas de las funciones que al final implementemos, serán producto de nuestra investigación personal a través de foros donde se mencionen las soluciones a los diversos problemas o funciones nuevas que podamos utilizar.

Herramientas que simplifican el trabajo

Al final, si utilizamos una herramienta que nos simplifique el proceso de implementación, siempre será importante guardar un archivo, con las sentencias SQL generadas por la misma. De hecho, con cada modificación debemos guardar una copia de respaldo.

Herramientas web como PHPMyAdmin, son muy importantes. La implementación y las pruebas generalmente las realizaremos en un computador local y vía interfaz web, podremos hacer el cambio desde el mismo Servidor instantáneamente y transparente al usuario.

Por qué optimizar

Creo firmemente que la labor como desarrolladores es que los productos, superen las expectativas de nuestros clientes. La optimización de la base de datos no escapa al proceso de optimización.

Un mal proceso de optimización a la Base de Datos, generará que el sistema sea inestable, poco fiable, con posibilidad de la información duplicada, lento para las transacciones, etc. Ahora bien, en el Modelo de Desarrollo la razón por la cual es necesario optimizar, es por que el modelo ve que cada aplicación no está exenta a ser actualizada.

Las aplicaciones, entornos de desarrollo y tecnologías van cambiando considerablemente. No podemos pretender que nuestro proyecto, siga funcionando por la eternidad en la versión del sistema en la que lo dejamos. El hacer tal cosa, solamente demostrará una mala calidad de trabajo y poca visión sobre el futuro de nuestra aplicación.

Los SGBD no cambian tan vertiginosamente, como otras tecnologías. Por lo cual, optimizar nos permitirá hacer un sistema adaptable, que utilice lo mejor del sistema y que pueda escalar sin problemas, dentro de un corto plazo, cuando veamos que la nueva versión, cumple y sobrepasa nuestras espectativas. Debemos siempre estar abiertos al cambio, pero utilizar lo mejor que haya en el momento presente.

En concepto de desarrollo escalado como cambiar de tecnología de BD sin alterar el modelo. Hasta este momento, muchos lectores preguntarán, por qué hacer tanto énfasis en cambiar de tecnologías. Uno de los motivos es la escalabilidad.

La importancia de la demanda

Dentro de los SGBD, existen muchas soluciones que nos brindan diferentes capacidades y características. Es muy común en la actualidad que los entornos de trabajo, se desarrollen para cumplir con metas a corto plazo y a medida que la aplicación, su entorno de trabajo y sus usuarios va en aumento; la aplicación debe responder a esas demandas, brindando mayor soporte a una mayor demanda de servicios.

Ahora bien, es probable que ante esta demanda de nuevos servicios, nuestro SGBD actual se quede corto en prestaciones y debamos mudar a otro gestor, sea por un mejor rendimiento a mayores transacciones, más requerimientos de seguridad, cambio de hardware y proveedor de software, etc.

Una aplicación, atada por completo a una sola plataforma, está condenada a desaparecer junto con la misma. Como desarrolladores, debemos ser previsores de tales acontecimientos, haciendo sistemas escalables.

Cuando separamos el modelado de Datos, estamos relegando al SGBD de turno, las operaciones de manipulación, control y actualización de los datos. Todos los sistemas actuales, ofrecen capacidades de programación de vistas, funciones, procedimientos y los tan famosos triggers.

Es importante que si utilizamos un sistema de desarrollo de este tipo, pensemos siempre en la generalización de su uso. La lógica de programación depende del modelado de Datos. Al centralizar las operaciones de mantenimiento de la información en el SGBD, y separar las funciones especiales que solo puede realizar el lenguaje, estamos independizando la Base de Datos del lenguaje de Scripting.

Si cambiamos de plataforma, y conservamos nuestro SGBD, la aplicación seguirá funcionando de la misma manera. Sea que cambiemos de lenguaje de programación, que utilicemos varios al mismo tiempo o que migremos a la versión posterior, siempre el modelo se mantendrá intacto.

Sería una práctica interesante, la de separar en un archivo en formato XML o de otro tipo, las diferentes consultas que generamos a la base de datos. A si, el lenguaje podría ir a leerlas. Así separamos y centralizamos aún más. Está practica sería de mayor importancia si combinamos tecnologías. Un esquema podría ser:

<?xml version = "1.0" ?>
<database engine = "mysql" version = "5.0">
      <section type = "views">
            <view id = "72A35SRT"> SELECT * FROM `_employees`</view>
            <view id = "ERT56QS8"> SELECT `email` FROM `_clients`</view>
      </section>
      <section type = "functions">
            <function id = "8954DAER" success = "7946">
                  SELECT `user_exists`('%username%')
            </function>
      </section>
</database>

Centramos en un archivo todos los Queries, identificándolos con un ID. Esto podría conllevar un mayor procesamiento para el servidor, pero si optimizamos correctamente, podríamos llegar a mejor la respuesta, con un sistema de cache interno. El archivo podría ser accedido por cualquier script, debemos tener un cuidado especial para evitar la irrupción de terceros.

Manejo y optimización del almacenamiento y las funciones de gestión del contenido

Consideremos un ejemplo sencillo: imaginemos que estamos desarrollando una aplicación y que un procedimiento se debe realizar en varias partes de nuestro código. Que sería lo más conveniente a realizar: copiar una y otra vez el bloque de instrucciones o crear una sola función o procedimiento.

Esta misma situación ocurre, cuando programamos y ejecutamos consultas a la Base de Datos. Es increíble como nuestro código empieza a crecer en ambas direcciones de nuestro editor. Además, no solamente debemos fijarnos en ese aspecto.

Al mandar consultas desde el lenguaje de Scripting a la Base de Datos, el SGBD, debe interpretarla y ejecutarla. Obviamente, esto lo hace en milésimas de segundos. Pero, cuando hablamos de alrededor de mil consultas o más por segundo, el tiempo que se tarda por cada transacción es vital.

¿Cómo podemos solucionar este inconveniente y hacer que nuestra base de datos responda en un mejor tiempo?

La respuesta es utilizar procedimientos, funciones y vistas. Al estar dentro de la base de datos, estos suelen ser más rápidos, por que el SGBD, lo ha interpretado, depurado y optimizado con anterioridad, lo cual hace que las consultas sean más rápidas.

La consulta general es:
INSERT INTO `lands`(`land_id`, `landname`, `area`, `lang`)
            VALUES ("gt", "Guatemala", "108880", "es"); 

Y cambiaría a: 

SELECT `addland`("gt", "Guatemala", "108880", "es")
<-- 

En lugar de mandar un query de inserción a una base de datos desde el script, es más sencillo, mandar los parámetros a la función almacenada en el SGBD. Dentro de la función está la consulta ya compilado.

Además, al centralizar las consultas, cualquier cambio hecho, alterará a todos los procedimientos del lado del script que lo utilicen. Esto ahorrará tiempo de desarrollo y mejorará el mantenimiento de la aplicación en su totalidad.

Conclusiones

Una buena separación de los componentes permitirá que nos enfoquemos en cada área de manera adecuada. Cuando tengamos que dar mantenimiento, iremos al punto exacto de la aplicación. Una buena estructura, generará mejores resultados y mayor rendimiento.

En el próximo artículo, veremos como debemos implementar la parte de programación. Aprenderemos más acerca de la optimización de la aplicación y comentaremos acerca de como se vincularía la tecnología del servidor, con la tecnología del explorador.

Descargar el ejemplo.

Lecturas relacionadas:

• Desarrollo multinivel para aplicaciones basadas en el web

---

Juan Manuel Lemus para Maestros del Web.
Agrega tu comentario | Enlace permanente al artículo

---

Síguenos en: @maestros | Fan page

]]> http://www.maestrosdelweb.com/editorial/modelado-de-datos-e-implementacion-de-la-base-de-datos-primer-nivel-l5/feed/ 14 Juan Manuel Lemus http://www.maestrosdelweb.com/editorial/desarrollo-multinivel-para-aplicaciones-basadas-en-el-web/ http://www.maestrosdelweb.com/editorial/desarrollo-multinivel-para-aplicaciones-basadas-en-el-web/#comments Thu, 27 Sep 2007 07:00:37 +0000 Juan Manuel Lemus http://www.maestrosdelweb.com/editorial/desarrollo-multinivel-para-aplicaciones-basadas-en-el-web/ Desde la programación procedimental hasta el Modelo de desarrollo MVC (Model, View & Controller), las diferentes metodologías de desarrollo han evolucionado, conservando un fin común: la total integración de componentes reutilizables y la separación de los niveles de programación.

Existen bastantes métodos de desarrollo multinivel en la actualidad. Muchos fueron pensados originalmente para la programación de aplicaciones tradicionales orientadas a un tipo de Sistema Operativo en particular.

Posteriormente, fueron adaptadas para su implementación en entornos de desarrollo orientados al web. Sin duda, algunos de ellos son eficaces en cualquier plataforma. Pero el hecho de que hayan sido concebidas primeramente para entornos tradicionales, no permite explotar el potencial que se tiene, al programar para la web.

El modelo MVC

El modelo con mayor auge en la actualidad es el modelo MVC. Sobre este modelo existe una serie de implementaciones como Ruby on Rails o Cake PHP. La ventaja fundamental del modelo es la separación de la lógica de programación en tres partes: Modelo, Vista y Controlador.

Según experiencias de programadores que han utilizado este modelo de desarrollo, el mismo se adapta perfectamente para proyectos pequeños, pero a medida que la complejidad del proyecto se incrementa, cada vez es más difícil llevar una integración perfecta sin afectar las demás estructuras.

Puede resultar bastante complicado seguir con el desarrollo de una aplicación con un nivel de complejidad mayor, sino contamos con la adecuada experiencia en el manejo del concepto.

En lo particular, veo un serio problema en esta situación, además de que el uso del modelo, utilizando cualquier tecnología como Ruby on Rails u otros frameworks de desarrollo, hasta por completo nuestro proyecto a tal o cual tecnología.

Esto puede ser un serio problema, si contamos con que la tendencia de nuevas herramientas mucho más fáciles de utilizar, están siendo desarrolladas continuamente y sus variantes son implementadas, como paquetes independientes de cualquier plataforma.

Hay mucho potencial en cualquier tecnología orientada al desarrollo de aplicaciones para Internet. Existen bastantes lenguajes de scripting, en la actualidad y todos brindan una excelente solución para un rango determinado de necesidades. ¿Por qué no utilizar las mejores características de cada lenguaje para el desarrollo de aplicaciones?

El modelo L5

El modelo L5, como le he llamado, es un modelo orientado, completamente, al desarrollo de aplicaciones para Internet. Este modelo no es una derivación del modelo de desarrollo MVC.

Es una división completa de las partes de integran el proceso de realización de cualquier proyecto orientado a Internet en el cual, la división la constituye las ramas de tecnologías que intervienen en una aplicación orientada a Internet. Así, el modelo se divide en 5 grandes áreas:

• Modelado de Datos
• Lógica de Programación
• Estructura de Contenido
• Diseño de la Interfaz
• Maquetación e Implementación

Estos cinco puntos son el pilar de este modelo. Adicionalmente, cada uno tiene un grado de división que puede ser propuesto por el equipo de desarrollo, dependiendo de la complejidad del proyecto.

Aquí no está incluido la fase de Análisis y la definición de Metas que es obvio que necesita existir para que estos puntos puedan llevarse a cabo; la guía sobre la que descansa cualquier proyecto de desarrollo.

La justificación de separar el modelo en cinco entidades, es bastante sencilla. Consideremos el desarrollo tradicional de un proyecto sencillo como por ejemplo un sitio de una pequeña empresa con un administrador de contenidos.

Trabajando con un administrador de contenidos

Si contamos con un administrador de contenidos, lo más común es que usemos una implementación de Base de Datos (MySQL, Oracle, SQL Server), relacionada con el contenido y accedida a través del lenguaje de scripting que hemos implementado (PHP, ASP.Net, Java, Ruby).

Debemos contar con un diseño de interfaz y el producto final es la página vista en el explorador (HTML, CSS, JavaScript). Si nos damos cuenta, existe varias tecnologías involucradas en el producto final. Todas con una tarea específica. Este modelo es aplicable en cualquier nivel de definición y complejidad de un proyecto.

El punto de inicio de cada proyecto se centra en la definición del modelo de la Base de Datos y del modelo de relaciones de los datos. Esta filosofía se enfoca en el hecho de que separar cada uno de los puntos mencionados, proporcionará el verdadero dinamismo que debe tener una aplicación.

Por ejemplo: en el apartado de la definición de la base de datos, relegamos por completo el manejo del almacenamiento y las funciones de manejo de datos al SGBD, sea cual sea. Con esto nos garantizamos un rendimiento absoluto y un máximo aprovechamiento.

También, el punto que se quiere destacar es que cada uno de los elementos y tecnologías que integran el modelo puede ser reemplazo sin que esto afecte por completo los procesos subsiguientes.

La programación adaptada a módulos

Para el segundo punto, la programación, elegimos tecnologías que se adapten a cada módulo que se desarrolle. Con esto podemos aprovechar al máximo el uso de una tecnología para una parte del esquema y utilizar diferentes tecnologías dentro del proyecto, con lo cual, cada modulo se puede hacer de una manera optima, y sencilla por que estamos utilizando la mejor tecnología para su desarrollo.

La Estructura de Contenido es uno de los más importantes y por así decirlo el punto de inflexión dentro del desarrollo. Aquí generamos un esquema de modelado de contenido. Es decir, en el desarrollo de la base de datos, optimizamos el manejo de la información, en el área de programación optimizamos los procesos y construimos el punto de unión entre el contenido y el almacenamiento.

En la programación no debemos generar consultas completas a la base de datos (sino llamadas a funciones y vistas almacenados en el SGBD). Las salidas deben estar en un formato estándar entre tecnologías como XML.

El contenido debe estar en un formato estándar. Esto permitirá su manipulación a cualquier dispositivo. El Diseño Gráfico de la Interfaz es la definición de plantillas para el diseño general del sitio y el último punto es la maquetación general del sitio con la integración y la interpretación del contenido generado. Este aspecto también es reemplazable. En si, todos los puntos son reemplazables y escalables.

Diseño inicial:

• MySQL
• PHP
• XML
• Diseño a Tres Columnas
• XHTML 1

Reemplazar por:

• SQL Server
• PHP
• XML
• Diseño a Tres Columnas
• XHTML 1

Actualización

Sin cambiar toda la estructura, en una nueva actualización podríamos quedar como:

• SQL Server
• ASP.Net
• XML
• HTML 5

Un cambio radical, pero el modelo sigue bastante intacto, como al principio.

Ventajas

Son muchas las ventajas que se desprenden de realizar un proyecto basado en esta metodología. El modelo es fácilmente utilizable en proyectos sencillos y complejos. Simplemente bastará con saber identificar de manera clara a los actores dentro del proceso y definir las funciones.

Muchas soluciones de terceros que podamos utilizar pueden ser fácilmente agregadas al proyectos dentro del nivel correspondiente sin afectar el desarrollo de los demás niveles. La combinación de tecnologías puede ser una gran ventaja.

Muchas de las soluciones realmente optimas para nuestro proyecto, si son de terceros, podrían no estar disponibles en nuestro lenguaje de scripting principal, por lo cual su utilización sería imposible.

Pero, no necesariamente debemos utilizar múltiples tecnologías dentro del proyecto. Si el proyecto no lo requiere o contamos con todos los elementos disponibles, podremos fácilmente, elegir por una solución.

Lo importante del desarrollo es que el producto final, cumpla con las necesidades requeridas. La optimización es muy importante. El modelo L5, hace mucho énfasis en ello. Al final, de cada desarrollo se pretenderá que hayamos construido una estructura de programación estable y sobre todo reutilizable.

Podemos dividir asimismo, los desarrollos de sub-módulos por clases, módulos y paquetes completos, con sus características dependencias. Siempre la estructura es interdependiente. El mayor reto sería crear una base sólida multinivel.

Desventajas

Las desventajas aparentes están relacionadas, dentro del proyecto en si. El utilizar múltiples tecnologías, demandará un mayor grado de conocimiento por parte del grupo de desarrolladores. Recordemos, que este punto no es necesario, pero si muy útil a la hora de hacer aplicaciones escalables.

La metodología demanda que el equipo esté conformado por profesionales con mayor conocimiento en todas las tecnologías: desde la implementación de la Base de Datos, hasta la Maquetación.

El otro punto, consistirá en que posiblemente necesitemos mayores recursos para poder diseñar un proyecto. Muchos, podríamos tener un proyecto publicado en algún servidor compartido, y esto podría llegar a ser desventajoso, debido el grado de personalización y requerimientos que podríamos llegar a alcanzar dentro de la aplicación.

Oportunidades

Todos las metodologías, brindan un sin número de oportunidades. Algunas son únicas para cada método.

Entre las oportunidades destacan un mejor control dentro del proyecto, sencillez de actualización y de proceso de depuración y mantenimiento, y que, preferiblemente, al final de cada desarrollo, contaremos con mejores herramientas, reutilizables en posteriores proyectos o en la escalabilidad de antiguos desarrollos.

Retos

Si somos profesionales en tal o cual filosofía de desarrollo, siempre el cambio de perspectiva, nos causará cierto grado de incertidumbre y malestar. Es normal. Uno de los retos para los nuevos emprendedores, será la tentación de volver a las viejas prácticas. El sistema, demandará cierto grado de disciplina.

Si no nos guiamos dentro de los parámetros de desarrollo, podríamos estropear el proceso. Talvez, no lo veamos dentro del producto final, pero en un futuro, podremos toparnos con serios problemas dentro de la estructura de la aplicación. La optimización, puede ser un proceso laborioso, pero debemos recordar que al final, este punto es vital para cualquier aspecto.

Las tecnologías en el Internet, están cambiando constantemente. Como anécdota personal, antes de la redacción de este artículo, recién me entero de otro lenguaje de programación, mucho más rápido que ofrece muchas oportunidades.

Realizar una aplicación que sea optima para el presente y que pueda ser sujeta de grandes cambios, dentro del ciclo de funcionamiento, puede ser un gran reto, pero ciertamente, como equipo o como profesional independiente, nos brindará más de una satisfacción.

Te invitamos a que estés pendiente de la serie de artículos relacionados con el desarrollo multinivel para aplicaciones basadas en el web, que estaremos publicando durante las siguientes semanas.

---

Juan Manuel Lemus para Maestros del Web.
Agrega tu comentario | Enlace permanente al artículo

---

Síguenos en: @maestros | Fan page

]]> http://www.maestrosdelweb.com/editorial/desarrollo-multinivel-para-aplicaciones-basadas-en-el-web/feed/ 31 Juan Manuel Lemus