Hoy he visto en varios sitios cómo poner en los enlaces un icono del tipo de archivo al que se hace referencia. Algo parecido contamos hace ya tiempo, y al igual que en el ejemplo actual, no funciona para IE6, y aunque nos pese, aún hay muchas personas que siguen usando este navegador.
Una solución es realizarlo mediante Javascript, para lo cual tan solo deberemos incluir un pequeño script en nuestras páginas. El script tiene un array con expresiones regulares que detectan determinadas href y la url del icono para incluirlo en el estilo del enlace. Además existe una función que añade al evento onload del window una función que selecciona todos los enlaces, comprueba por cada enlace si cumple alguna de las expresiones regulares y si es asà modifica el estilo con el icono correspondiente.
var listaiconos = new Array();
listaiconos[listaiconos.length] = new Array(/youtube\.com\/watch\?/, "icons/icon_film.gif");
listaiconos[listaiconos.length] = new Array(/sevenload\.com\/videos\//, "icons/icon_film.gif");
...
window.onload = function() {
var enlaces = document.getElementsByTagName("A");
for (var i=0; i<enlaces.length; i++) {
var ok = false;
for (var j=0; j<listaiconos.length && !ok; j++) {
if (enlaces[i].href.match(listaiconos[j][0])) {
enlaces[i].style.paddingRight = "20px";
enlaces[i].style.backgroundImage = "url("+listaiconos[j][1]+")";
enlaces[i].style.backgroundColor = "transparent";
enlaces[i].style.backgroundRepeat = "no-repeat";
enlaces[i].style.backgroundPosition = "right center";
ok = true;
}
}
}
}
Ya hace tiempo explicamos como hacer un autocompletado en cajas de texto, pero claro, no todo el mundo tiene ganas o tiempo de hacerlo uno mismo. Por ello, no hay nada mejor que usar scripts de otras personas que nos facilitan el trabajo. SearchField es un javascript no obtrusivo que nos permite añadir sugerencias de búsqueda en nuestras cajas de texto de forma rápida y sencilla. Tan solo hay que añadir un javascript y enlaces a las librerÃas y a los estilos, para que funcione.
La única pega que le veo es que las palabras de sugerencia están dentro de una variable Javascript y no se realizan mediante llamada Ajax para poder asà obtener datos dinámicos, pero bueno, no parece complicado modificarlo para que permita esta opción. Style Your Website’s Search Field with JS/CSS
VÃa / WebAppers
Cuando se trabaja en una empresa de desarrollo de software es muy común que entres en un proyecto que ya está empezado, por lo que deberás tratar con un código que no es el tuyo, y que da igual que sea bueno o malo, deberás adaptarte a él, algo que siempre puede dar algún problema. Más problemático es cuando sustituyes al único encargado del código y el traspaso de conocimientos se realiza en un par de horas (algo muy frecuente en las grandes empresas de consultoría).
Para aquellos que se encuentren en esas circunstancias, espero que los consejos que os voy a comentar, sacados de mi propia experiencia en el desarrollo web, os sean de utilidad.
Echa un vistazo preliminar
Aún no sabes cómo es el código, si es bueno o es malo, pero un vistazo preliminar a la estructura de directorios y a los nombres de los ficheros suele darte una idea aproximada de la funcionalidad que pueden tener.
Por muy malo que sea un programador, éste tiene su propia lógica para la nomenclatura, échale un rato a intentar adivinarla y así podrás localizar ficheros de forma más sencilla en futuras modificaciones.
No esperes un diseño MVC claro, quizás ni exista y esté todo mezclado. Tú tienes tu forma de programar, pero aunque para ti sea perfecta, ni quizás lo sea, ni todo el mundo la comparte.
No intentes entenderlo todo de golpe
Lo más seguro es que no debas cambiar toda la aplicación de golpe, por lo que de poco te va a servir empezar a estudiarla completamente y entender todo su significado. Ve por partes, si tienes que hacer un cambio en una parte céntrate en esa parte del código y olvídate del resto.
Cuando te hayas pegado con una parte del código no se te olvidará fácilmente, por lo que si en otra ocasión tienes que volver a tocar esa parte te será más sencillo.
Empieza por el final para llegar al origen
Afortunadamente el resultado del desarrollo web es visible para todos, tan solo debes ver el código HTML para ver qué se ha generado con la aplicación.
Normalmente, las modificaciones que se suelen realizar son del tipo “en tal página falla tal cosa”. Mira el HTML de esa página y encuentra algo que pueda ser exclusivo de ella.
Busca nombres de clases de etiquetas, las cabeceras de las páginas (<h1>..<h6>), textos explicativos. Una vez creas que tienes un texto más o menos exclusivo de esa página busca entre todo el código, por ejemplo en Windows puedes usar GlobalFind.
Debes tener cuidado porque a veces el código no aparece exactamente como lo buscas. Por ejemplo un texto largo puede estar dividido en varias líneas:
$texto = 'Texto largo que el desarrollador ';
$texto .= 'a cortado en líneas para verlo más claro, ';
$texto .= 'aunque sea menos eficiente por tener que ';
$texto .= 'concatenar strings.';
O también puede darse la circunstancia de que el texto se forme por la unión de un texto y una variable:
$clase = array('empleados', 'facturas', 'resumen');
// Algo de código por aquí
echo '<div class="'.$clase[$tipo].'">...</div>';
// Más código
Quizás te encuentres con ficheros de idiomas, y verás que el texto que buscas está asociado a un código, céntrate en ese código y búscalo.
Usa trazas
La lógica del código es de todo menos lógica. Te vas a encontrar con partes de código que no vas a entender por mucho que lo estudies. No es bueno perder el tiempo intentando entender el código al 100%, ya tendrás tiempo para ello.
Cuando te encuentres con un trozo de código que no entiendas, métele trazas a todos los bloques para saber por dónde pasa:
echo 'Empezamos';
if ($condicion1 && $condicion7) {
echo 'Paso por aquí 1';
// código
if ($condicion3 || !$condicion4) {
echo 'Paso por aquí 2';
// código
} else {
echo 'Paso por aquí 3';
// codigo
if ($condicion5) {
echo 'Paso por aquí 4';
}
}
} else {
echo 'Paso por aquí 5';
// código
}
echo 'FIN';
Fijándote en las trazas que devuelva verás que código se ejecuta y así podrás encontrar mejor el error.
Ten en cuenta la base de datos
La BD es muy importante a la hora de localizar información. Mucha gente usa la BD para almacenar los mensajes de error o de información, que serán fundamentales para comprender el funcionamiento de la aplicación.
Localiza dónde se ejecutan las consultas, si hay suerte estarán separadas del resto de código (normalmente a las clases que tratan con la BD se le llama modelos). Si tienes que modificar los datos que devuelve una consulta, aunque no sepas cómo se obtienen esos datos (la sentencia SQL exacta), si que puedes hacerte una idea de las tablas a las que accede. Busca entre los modelos el nombre de esas tablas y filtra por los campos que muestra en la página. Claro que el select * from puede ser nuestro mayor enemigo.
Examina los datos de la tabla para ver si coincide con los datos que se muestran. Un ejemplo sencillo es insertar un registro mediante la aplicación y ver qué se ha guardado en la BD, así entenderás más facilmente qué se guarda en cada campo.
No olvides los ficheros de configuración
En ellos está mucha de la lógica de la aplicación, estudiarlos durante un rato puede aclararnos muchas cosas, como por ejemplo rutas de ficheros, conexiones a la BD, sistema de trazas, clases auto-ejecutables…
Cuidado con las aplicaciones externas
Si programas en Java es posible que no encuentres el por qué de un problema porque quizás la ejecución dependa de un JAR externo. Localízalos y tenlos siempre presentes. Si trabajas con Linux o Unix puede que haya llamadas a la shell. Pasará algo parecido a los JAR, deberás saber dónde están y qué hacen.
Empieza por los cambios sencillos
No intentes poner la aplicación del revés o cambiarla radicalmente nada más empezar con ella. Ve poco a poco, con cambios sencillos, que te hagan enfrentarte con el código y empezar a conocerlo.
Los cambios que puedas realizar en una parte no sabes donde van a poder afectar, por eso debes ir con cuidado y empezando con cosas sencillas, que tendrán menos posibilidades de estropear otras cosas.
Un cambio en varios lugares
Reutilizar código no siempre es una norma para los desarrolladores. Aunque creas que has localizado el lugar dónde debes cambiar el código, no pienses que es el único lugar. Sigue buscando a ver si hay más lugares donde se deba cambiar.
Testea constantemente
No conoces la aplicación y no sabes que puedes estropear cuando tocas algo. Un cambio sin importancia puede hacer que todo falle, ten cuidado si arreglas algo de no estropear otra cosa.
El uso de herramientas web open source es muy frecuente tanto en proyectos personales como profesionales. Existen alternativas de código abierto para casi todo lo que podemos necesitar: blogs, CMS, gestión de proyectos, galerías de imágenes, … Desgraciadamente, algunas veces estos proyectos open source no son demasiado “buenos” y trabajar con ellos puede ser un verdader suplicio.
Quizás hablo desde la desesperación que sufro últimamente por tener que lidiar con el desarrollo de otros, pero me gustaría compartir una serie de aspectos que debería tener un proyecto web open source, sobre todo aquellos que ya tienen unos cuantos años, lógicamente, sin desmerecer el trabajo altruista de nadie.
Buena documentación: imprescindible, ya sea para el usuario como para el desarrollador.
MVC: bueno, cualquier proyecto debería seguir esta arquitectura, pero en el caso de un proyecto open source en el que cualquiera puede echar mano al código, se convierte en algo absolutamente necesario ya que normalmente se requiere una personalización y si se ha de tocar el core para realizar los cambios necesarios, mal vamos. Además, el MVC te permite quitar las odiosas tablas que te encuentras en muchos proyectos.
Plugins: el proyecto deberá permitir que otros añadan funcionalidades a tu código. El éxito de un proyecto open source depende de la comunidad, y es la comunidad la que se suele encargar de los plugins. En versiones iniciales es posible que esta funcionalidad no exista, pero debería ser una futura implementación.
Themes: para proyectos de CMS, blogs o con frontend público, siempre viene bien tener una lista de themes donde poder elegir y diferenciar tu aplicación de otras similares. Además, también es un origen de colaboraciones por parte de la comunidad (al igual que los plugins) y existen numerosas webs o empresas que ofrecen themes de pago, lo cual aporta negocio e interés para los usuarios/desarrolladores.
I18N: aunque muchos estamos acostumbrados al inglés, es necesario que el proyecto permita la internacionalización para que existan versiones en diferentes idiomas; a todo el mundo le gusta usar las aplicaciones en su propio idioma.
Comunidad: el Santo Grial, si tienes comunidad, tendrás éxito (o casi). Creo que esto debe ser lo más complicado de obtener, porque en parte no depende de tí, depende del gusto de los otros desarrolladores, por eso, quizás, los puntos anteriores sean tan importantes.
Foro: aunque algunos crean que los foros están obsoletos, no hay nada más utilizado y necesario que un foro para resolver dudas, sobre todo si existe un foro mayoritario y no tienes que buscar en otros 100, y más importante aún, que las respuestas las ofrezcan, entre otros, los desarrolladores del proyecto open source.
Gestor de errores: da igual si es Trac, Bugzilla u otro similar. El problema de todo proyecto es la detección, corrección y seguimiento de errores, si se ofrece una herramienta para que la comunidad se involucre en esta fase el proyecto irá mucho mejor.
Gestor de versiones: SVN, git o similares, para que la gente se pueda descargar las últimas modificaciones
API: al igual que los plugins, permite que otros interactuen con tu aplicación, sobre todo desde otras aplicaciones diferentes, por lo que se añade riqueza al proyecto.
Código documentado: aunque exista una documentación del uso de las funciones “públicas”, siempre viene bien tener la documentación de core.
Sencillez: por favor, que para crear un plugin, módulo o componente no sea necesario crear 20 archivos y 30 directorios
Estándares: si todos vamos a nuestra bola, al final habrá que aprender 100 métodos distintos, siempre es mejor seguir los eśtandares y no volver loco al personal. Por ejemplo OAuth, no te crees tu propio método de autenticación porque si la gente lo necesita usar le causarás un inconveniente, y si no lo necesita usar se echará para atrás y cambiará de opinión porque no le apetecerá usarlo.
Interacción con otras aplicaciones: en el punto en el que nos encontramos es absurdo pensar únicamente en nuestra aplicación, ahora es necesario que todo se conecte con todo, no nos olvidemos de los archifamosos Google, Facebook y Twitter
Actualizado desde aquí
Administración: existe algunos proyectos que van por ficheros de configuración, lo cual no quiere decir que sea difícil de administrar, pero no todos los usuarios son avanzados y hay que poner las cosas fáciles a la gente.
Instalador: como bien dice Chema un instalador sencillo y paso a paso puede ser fundamental para el éxito del proyecto, ya que si la instalación es complicada, probablemente el usuario no avance y descarte usar nuestro proyecto.
No son nuevas verdades, pero aunque parezca mentira en muchos proyectos que he visto algunos puntos brillan por su ausencia y en otros se hace justamente lo contrario
Algo que parece de lo más sencillo a veces nos puede llevar más tiempo del que pensamos, el desarrollo de formularios, si queremos que sea bueno, puede ser muy variado, por eso os pasamos una recopilación de distintas implementaciones de formularios que hemos encontrado.
En ellos podrás encontrar desde el uso de fieldset y legend, maquetación sin el uso de tablas, división en grupos de datos, formularios dinámicos dependientes de selección de opciones previas y muchos otros más. CSS-Based Forms: Modern Solutions
VÃa / dzone
Hoy toca realizar conexiones con el servidor usando llamadas autenticadas. Para eso usaremos JWT (JSON Web Token), que viene a ser el envío de un token en cada llamada que necesita autenticación. El token está formado por tres cadenas codificadas en base64 y separadas por un punto (header.payload.signature). En el payload se envía toda la info que queramos, pero sin pasarse porque el token no debería ser muy largo y sobre todo sin enviar información sensible, porque el token no está encriptado, es por ello que la comunicación navegador/servidor debe ser mediante HTTPS. Si quieres una explicación más detallada, aquí te lo explican mejor.
En el payload vamos a guardar varios claims, entre ellos el username y un uuid que usaremos para validar que el usuario es correcto. JWT asegura que el token es válido, pero no viene mal añadir cierta seguridad. Cuando el usuario se loguea un nuevo uuid es generado, por lo que se comprobará si coinciden para el username enviado.
Ya tenemos la explicación teórica, ahora vamos con la parte de programación, primero la parte servidor y luego el frontend.
Lo primero que tenemos que hacer es añadir un nuevo plugin a hapi.js que se encargue de la autenticación, registrando un nuevo strategy a server.auth que use JWT. El plugin hapi-auth-jwt2 se encargará de toda la autenticación JWT y añadiremos una capa extra de validación comprobando que el username y el uuid coinciden.
Y por último añadimos una nueva ruta para autenticar (login) el usuario, comprobamos que el usuario y la contraseña coinciden, y si es así, creamos un uuid que guardamos en la bd y generamos el JWT y lo enviamos en la cabecera Authorization:
Vale, ya tenemos la parte del servidor, ahora la parte del frontend. Primero es añadir las rutas para /login, /account y /logout. He añadido un meta que indica si la ruta tiene que ser obligatoriamente autenticada, obligatoriamente no autenticada o como sea. Para ello, para cada ruta comprobará si el JWT token está almacenado o no y según el meta redirigirá a home o continuará:
Para gestionar el almacenamiento en el navegador en vez de cookies vamos a usar sessionStorage y localStorage para guardar el token JWT. Como el formulario de login permite recordar la sesión, vamos a usar ambos storages. Si no se recuerda usaremos sessionStorage, que se borrará cuando se cierra el navegador, en caso contrario usaremos localStorage.
import Config from'@/js/config';
/**
* API methods for sesion/local storage.
* Depending on `this.session` it saves only on `sessionStorage` or also in `localStorage`
*
* @since v0.8.0
*/classstorage{
/**
* Constructor
*
* @param {boolean} session If stored only in session
*/constructor( session = false ) {
this.session = session;
}
/**
* It saves the token in the session (and local storage is this.session === false),
*
* @param {strig} token JWT token
*/
setJWTToken( token ) {
sessionStorage.setItem( Config.jwt.storageKey, token );
if ( ! this.session ) {
localStorage.setItem( Config.jwt.storageKey, token );
}
}
/**
* It gets a value from session storage or in local if session = false
*
* @returns {string}
*/
getJWTToken() {
const sessionValue = sessionStorage.getItem( Config.jwt.storageKey );
if ( sessionValue ) {
return sessionValue;
}
if ( ! this.session ) {
const storedValue = localStorage.getItem( Config.jwt.storageKey );
return storedValue;
}
returnnull;
}
/**
* Removes JWT token from session and local storage
*/
removeJWTToken() {
sessionStorage.removeItem( Config.jwt.storageKey );
localStorage.removeItem( Config.jwt.storageKey );
}
}
exportdefault storage;
También hemos creado una librería para tratar las llamadas a la API. Hay dos métodos, uno para autenticar el usuario (login) que mirará la cabecera Authorization, y otro método que obtiene los datos del usuario actual realizando una llamada autenticada enviando el JWT token en la cabecera Authorization:
import Config from'@/js/config';
import Storage from'@/js/utils/storage';
/**
* API backend methods
*
* @since 0.8.0
*/classapiFetch{
/**
* Authenticate an user, if ok, JWT token is sent by the server in Authorization header
*
* @param {string} username User name
* @param {string} password Password
*
* @returns {Promise}
*/
auth( username, password ) {
return fetch( Config.api.user.auth, {
method: 'POST',
body: JSON.stringify(
{ username, password }
),
mode: 'cors',
} ).then( response => {
const auth = response.headers.get( 'Authorization' );
if ( auth ) {
return {
response: true,
token: auth,
};
}
return {
response: false,
message: 'Username or password not valid',
};
} );
}
getUser( username ) {
return fetch( `${ Config.api.user.get }${ username }`, {
method: 'GET',
headers: {
Authorization: new Storage().getJWTToken(),
},
} ).then( response => response.json() );
}
}
exportdefault apiFetch;
Ahora solo faltan los controladores para login, account y logout. Login realizar la llamada al servidor y si se obtiene el JWT se guarda:
<template><sectionclass="section"><divclass="container"><h1class="title">
Login
</h1><divv-if="error"class="columns is-centered has-margin-bottom-2"
><b-notificationclass="column is-7-tablet is-6-desktop is-5-widescreen"type="is-danger"has-iconaria-close-label="Close notification"role="alert"size="is-small "
>
{{ error }}
</b-notification></div></div><divclass="container"><divclass="columns is-centered"><divclass="column is-5-tablet is-4-desktop is-3-widescreen has-background-light login-form"><b-fieldlabel="Username"><b-inputv-model="username"value=""maxlength="30"icon="account-circle-outline"
/></b-field><b-fieldlabel="Password"><b-inputv-model="password"value=""type="password"icon="lock-outline"
/></b-field><divclass="field"><b-checkboxv-model="remember">
Remember me
</b-checkbox></div><divclass="has-text-right"><b-buttontype="is-primary"
@click="submit"
>
Log in
</b-button></div></div></div></div></section></template><script>import ApiFectch from'@/js/utils/api';
import Storage from'@/js/utils/storage';
exportdefault {
name: 'Login',
// Form data and error messages if login fails
data() {
return {
username: '',
password: '',
remember: false,
error: '',
};
},
methods: {
// It logs in, using the backend API for authenticate the user data.// If user logs in, it saves the JWT token in the browser. If not, shows error message.
submit: function() {
const api = new ApiFectch();
api.auth( this.username, this.password )
.then( response => {
const storage = new Storage( ! this.remember );
if ( !! response.response && !! response.token ) {
storage.setJWTToken( response.token );
this.error = false;
// `go` refreshes the page, so user data is updatedthis.$router.go( '/' );
} else {
storage.removeJWTToken();
this.error = response.message;
}
} );
},
},
};
</script><stylelang="scss"scoped>.login-form {
border-radius: 4px;
}
</style>
Logout borra los datos JWT del navegador y redirige a home:
<template><sectionclass="hero is-medium is-primary is-bold"><divclass="hero-body"><divclass="container has-text-centered"><h1class="title">
{{ message }}
</h1><h2class="subtitle">
Miss you 💛
</h2></div></div></section></template><script>import User from'@/js/utils/user';
exportdefault {
name: 'Logout',
// Dummy data
data() {
return {
message: 'Bye',
};
},
// After being created it logs out and go to home
created() {
new User().logout();
// `go` instead of `push` because refreshing the page updates the user data// Maybe using vuex is a better way to do it, or not...this.$router.go( '/' );
},
};
</script>
Y Account recupera los datos del usuario una vez que ha creado el controlador:
<template><divid="account"><sectionclass="hero is-primary is-bold"><divclass="hero-body"><divclass="has-text-centered"><h1class="title">
{{ message }}
</h1><h2class="subtitle">
Your data
</h2></div></div></section><sectionclass="section"><divclass="container"><divclass="tile is-ancestor"><divclass="tile is-parent"><pclass="tile is-child notification">
Some content
</p></div><divclass="tile is-8 is-parent"><divclass="tile is-child notification is-info"><ulid="data"><liv-for="( value, key ) in user":key="key"
>
{{ key }} : {{ value }}
</li></ul></div></div></div></div></section></div></template><script>// Dummy componentimport ApiFectch from'@/js/utils/api';
import User from'@/js/utils/user';
exportdefault {
name: 'Account',
data() {
return {
message: 'Account',
user: {},
};
},
created() {
const user = new User().getCurrentUser();
new ApiFectch().getUser( user.username )
.then( response =>this.user = response );
},
};
</script>