Contenido

POM: Programación Orientada a Maquetadores

25 jul

+ 20

Entre diseñadores web y desarrolladores web siempre ha habido una línea un tanto difusa entre las funciones de uno y las funciones de otros. En esa línea difusa aparece el perfil de maquetador que en muchas empresas recae entre las funciones de uno o de otro.

Si nos ponemos tiquismiquis podemos sacar muchos más perfiles, pero para este artículo nos bastará con estos 3  :D

Proceso de creación

Para entendernos un poco mejor, explico lo que entiendo por un proceso de creación de una aplicación web, partiendo de que se haya hecho (o no…) un buen análisis, con su correspondiente toma de requerimientos y si ya estás en una empresa seria de verdad, un proceso de validación de prototipos, y especificaciones… pero solo si es una empresa seria de verdad, no vale con ir de ello…

En ese punto, una vez aprovado todo por el cliente, remarcado y explicado perfectamente lo que se ha pedido y lo que se ha de entregar, se comienza a trabajar.

En este punto, los diseñadores empiezan a darle forma a esos prototipos, esos wireframes que el usuario a validado y que espera recibir. Una vez terminados estos diseños, generalmente en formato imagen, se le muestran al usuario para que valide el diseño de la página y pasemos a darle funcionalidad a la misma. (Ojo!, creo que estoy entrando en un mundo utópico rodeado de unicornios y dragones… :D).

Vale, ya hemos validado con el usuario el diseño y la funcionalidad que desea para su nueva y flamante nueva aplicación web, ha sido un proceso duro, pero nos permite disponer de toda la información necesaria para empezar y no tener que volver a molestar al usuario, salvo las notificaciones periódicas que se planifiquen.

En este punto, el diseño se pasa a los maquetadores, encargados de convertir ese diseño en el HTML que el usuario podrá ver en su navegador, este HTML no contendrá ninguna funcionalidad, únicamente habrá HTML y CSS.

En este punto, entramos una zona pantanosa, ya que nos encontramos código javascript que necesita el diseño para ser funcional (sliders, autocompletes, ….). Soy de los que cree que esta responsabilidad debería caer en el maquetador, ya que es el que está más cerca del diseñador para saber que funcionamiento ha de tener esa porción de web concreta.

Por otro lado, nos encontramos con que hay ciertas funcionalidades que afectan, tanto al maquetador como al desarrollador web, por ejemplo los autocompletes (suggest), validación de formularios, … esta funcionalidad es a veces un poco difusa. En este punto entra lo que yo llamo, en alarde de originalidad POM (Programación Orientada a Maquetadores).

POM: Programación Orientada a Maquetadores

Se trata de ofrecer al maquetador una serie de herramientas que le permita añadir funcionalidad básica al HTML sin necesidad de tocar una sola línea de Javascript. Básicamente se trata de generar componentes autónomos que lean el HTML y los atributos especiales que este HTML ha de tener.

Hace ya mucho tiempo, publiqué un ejemplo de validación de formularios con jQuery que seguía esta metodología. Se basaba en indicar a cada elemento de que tipo de validación requería para comprobar los datos de entrada. A grandes rasgos, vemos que usando el class de los atributos <input />, <select />,… informábamos el tipo de validación.

Atributos data-*

Entonces llegó HTML5 y sus atributos data-*, unos atributos que abren un abanico de posibilidades, y aunque antes me daban un poco de miedo, ahora disfruto con ellos :D

Los atributos data-*, nos permiten dotar a nuestros elementos de un montón de datos que podemos usar en nuestro código javascript, de forma que podremos construir un código capaz de trabajar con ellos y construirse en función de ellos.

Veamos un ejemplo:

<input type="text" class="autocomplete estilobonito" data-max-items="15" data-type="clientes" data-min-length="3" />

// jQuery
$("input.autocomplete").bind(function(){

	// Recogemos valores
	var $this = $(this),
	 	$value = $this.val(),
		$maxitems = $this.data("max-items") || 5,
		$type = $this.data("type") || "compras", 
		$minlength = $this.data("min-length") || 5;
	
	
	/* Funcionalidad */
	
	// Salimos si ha pulsado menos de $minlength carácteres
	if ($value.length < $minlength) return;
	
	jQuery.getJSON("http://miservicio.com/", {
		type: $type,
		items: $maxitems,
		value: $value
	},function(){
		/* LO QUE QUIERAS HACER*/
	});
});

Como podemos ver, nos permita acceder a ellos fácilmente, sin jQuery y para IE es igual de fácil.

¿Donde está la gracia?

La gracia está en hacer el código lo más reutilizable posible, haciendo que nos permita configurar nuestros elementos HTML de forma fácil. En mi caso personal, esta programación ha conseguido descargarme bastante de trabajo que antes hacía yo para que ahora los maquetadores/diseñadores puedan configurar.

Por experiencia, puedo decir que siempre terminas modificando el código y adaptando el código a las diferentes necesidades del diseño, pero se convierte en una tarea más sencilla y fácil de depurar.

Un ejemplo que estamos usando y que nos funciona muy bien, a ver si un día puedo implementar una versión de demo para que la veáis, es un autocomplete usando el de jQuery UI, capaz de diferenciar entre 3 o 4 tipos diferentes de datos y 3 o 4 salidas diferentes que comparten prácticamente todo el código.

Esto, añadido al modelo de programación modular que vimos hace ya muuucho tiempo, nos está dando unos muy buenos resultados, tanto a la hora de desarrollar como a la hora de depurar la aplicación.

  • Hola! caí de casualidad buscando frameworks de desarrollo para html5, css3 y javascript, y me enganche con esta nota y los links que estuviste twiteando, muy buen contenido y además re interesante.. gracias por compartir =)

  • Muy bueno, lo empiezo a utilizar desde hoy mismo.

  • He utilizado una metodología similar, pero basándome en el plugin metadata de jquery (http://plugins.jquery.com/project/metadata)

    Muy buen post.

    • @bblanco: Para hacer esto no necesitas usar un plugin, el método data() te permite obtener el objeto json procedente del atributo.

    • @aNieto2k:
      Entiendo lo que me comentas, pero quizás fui muy escueto en mi comentario.
      Normamente desarrollo aplicaciones web con jsf, que es un framework de java para desarrollar básicamente aplicaciones web. Para construir las páginas, JSF te provee de sus propias etiquetas con sus atributos, es decir, para poner un campo de texto se pondría

      <h:inputText styleClass="fieldText" />

      esto generaría

      <input type="text" class="fieldText" />

      . Esto me limita ya que las etiquetas de jsf todavía no permite poner atributos data en los elementos. Por eso utilizo el plugin metadata, ya que gracias a él me permite añadir los “metadatos” asociados al elemento en el atributo class (styleClass en jsf). Lo comentaba por si alguien se ve atado como yo a utilizar un framework del tipo jsf, asp y demás que tienen sus propias etiquetas y todavía no tienen disponibles los atributos data-

    • @bblanco: Cierto, siendo así estás un poco atado.

  • A esto es lo que me referia con un post digno! :D

  • Jummmm que suerte sería vivir en una empresa así…. yo ultimamente en todos los sitios q he estado, ha habido diseñador y maquetador/programador (yo) y no le pidas al diseñador que maquete para ayudar pq se te tira encima… pero bueno en un mundo bonito fijo que se podría hacer todo esto :)

  • Me apunto a usarlo, buen post. Un Saludo Gracias.

  • Regularmente no está definido el perfil del diseñador | maquetador, regularmente el diseñador común contempla el diseño a lo fireworks-dreamweaver y desconoce estilos o código. En mi caso @Oyagum, no me lanzo encima al momento de maquetar, de hecho es parte del trabajo y representa la oportunidad de aprender más.

    Saludos!

  • Y yo que siempre que salen cuestiones de este tipo que se me va la mente a XML puro, namespaces propios, etc.
    Es decir, si usas cualquier lenguaje extensible de xml o incluso tu propia estructura, los límites del marcado (semántico y no visual siempre por supuesto) te los pones tú.

    Como ejemplo; hace tiempo hablaba en mi blog de las ventajas de object frente a img precisamente porque era más flexible en estas cuestiones. Con img estabas limitado a los atributos que establece el namespace en cuestión… que son los estándares más alt y src. Mientras que usando object, que además era el elemento estándar para imágenes, podías usar los parámetros (e incluso como contenedor) de forma semántica intrínsecamente y extensible para otros lenguajes.

    En relación a los data-atributos; tampoco fue necesario esperar a HTML5, ahí está el ejemplo de Facebook cuando empezó a usar su propio namespace para añadir atributos (no sé si mucho o poco semánticos) que dieran información a su API.

    En definitiva, personalmente pensar en XML como base estructural es sinónimo de casi la total libertad para hacer lo que quieras. El resto de tipos, basados o no en él, lo veo una especie de marcos de directrices a seguir para que esto no sea un popurri que ni dios se atreva a renderizar.

    En fin, como siempre un placer pasarse por Anieto2k ;)

Comentar

#

Me reservo el derecho de eliminar y/o modificar los comentarios que contengan lenguaje inapropiado, spam u otras conductas no apropiadas en una comunidad civilizada. Si tu comentario no aparece, puede ser que akismet lo haya capturado, cada día lo reviso y lo coloco en su lugar. Siento las molestias.