Posts etiquetados ‘Hardwebnet’

Feliz año a todos!!!

Quisiera compartir con vosotros un enlace al apartado de descargas de mi página web.

Allí podéis descargar gratuitamente tres juegos de escritorio y una aplicación para dispositivos Android:

  • VBAhorcado: clásico juego del ahorcado, programado íntegramente en Visual Basic .NET
  • JMastermind: emulador del clásico Matermind, programado íntegramente en Java.
  • Gana un millón: emulador del concurso de televisión “Atrapa un millón”, programado íntegramente en Visual Basic .NET
  • Aplicación “Numbering System Converter” para dispositivos Android: se trata de una calculadora que permite convertir cifras entre distintos sistemas numéricos (decimal, binario, octal y hexadecimal). La principal diferencia que presenta frente a otras muchas aplicaciones similares existentes en Google Play, es que permite operar con cifras extremadamente grandes sin ningún tipo de error, bug o desbordamiento. Muy útil para desarrolladores.

Espero que os gusten.

Enlace:

Descargas

Un saludo.

Canal de televisión dedicado a la formación e información sobre seguridad informática.

Altamente recomendable.

Canal en youtube

Página web

Una pequeña muestra:

Enlaces al canal de Chema Alonso.
Para aquellos que no lo conozcáis, decir que se trata de uno de los mejores hackers del mundo. Sí, del mundo.

Este señor es doctor en seguridad informática por la Universidad Politécnica de Madrid. Un jodido crack.

Sus vídeos y conferencias son de lo más instructivo e interesante para aquellos iniciados o profesionales dentro del fascinante mundo de la seguridad informática. Recomendables sin excusa.

Enlace al canal

Página web

Una pequeña muestra:

El polimorfismo está íntimamente ligado a la inyección de dependencias que vimos en el artículo anterior. Es una de las piezas fundamentales dentro de la programación orientada a objetos, así que intentaré poner un ejemplo muy sencillo para tratar de entender este concepto.
Supongamos que nos encontramos con este simple diagrama UML.

Diagrama UML

Diagrama UML


Como podemos observar, la clase Persona hereda de la superclase Humano, así como la clase Perro hereda de la superclase Animal. Cada una, por supuesto, tendría sus propias propiedades y métodos.
Supongamos también que nos encargan implementar el método “correr” para dichas clases. Podemos deducir que tanto la clase Persona como la clase Perro poseen la particularidad de poder correr, pero cada uno, evidentemente, lo hará de una forma diferente.
Lo inmediatamente lógico es pensar que la solución pasaría por heredar de otra superclase que implementara dicho método pero, como sabemos, Java, así como otros muchos lenguajes de programación, soportan herencia simple, con lo que esta idea cae por su propio peso. Además, aunque fuera posible, el acoplamiento entre las clases resultaría demasiado alto, con lo que la posiblidad de mantenibilidad y extensibilidad de la aplicación se vería en entredicho. Por ello, deberemos recurrir al polimorfismo. Veámoslo con un ejemplo práctico.
Lo primero que haremos será declarar una interface Corredor.
 

public interface Corredor {

	void correr();
	
}

 
La interface contiene la función común a nuestras clases Persona y Perro que, a partir de ahora tendrán que implementarla y por la tanto sobreescribir dicho método.
Así quedarían ambas clases:
 

public class Persona implements Corredor {

	@Override
	public void correr() {
		System.out.println("Yo corro como una persona");		
	}

}

 

public class Perro implements Corredor{

	@Override
	public void correr() {
		
		System.out.println("Yo corro como un perro");
		
	}

}

 
Por motivos prácticos, y para una mayor claridad del ejemplo, he obviado en el código que ambas clases heredarían cada una de su respectiva superclase. Ahora es algo irrelevante para la explicación que nos ocupa.
Como podemos apreciar, en el método “correr” de las clases he puesto simplemente una salida por consola. Con esto será suficiente para ver cómo reacciona nuestro programa.
Ahora vamos a crear una nueva clase a la que he llamado Facade (fachada), que será con la que interactue directamente el usuario de la aplicación.
 

public class Facade {

	public void correr (Corredor c){		
		c.correr();		
	}
	
}

 
La clase Facade cuenta con un método que espera recibir un objeto de tipo Corredor, es decir, que implemente dicha interface. A continuación llama al método correr de dicho objeto, pero ¿a qué método llamará? ¿Cómo sabrá hacía dónde dirigirse?. Pues aquí está lo realmente fascinante del polimorfismo. Como tanto la clase Persona como la clase Perro implementan la interface Corredor, al pasar una instancia de cualquiera de ellas como argumento, reaccionará llamando directamente al método “correr” de la clase correspondiente, sin importarle realmente de qué objeto se trata. Él solo sabe que debe llamar al método correr del objeto Corredor que le ha sido pasado.
ATENCIÓN: Aunque he llamado “correr” al método de esta clase Facade, se podría haber llamado de cualquier otra forma. En este caso no tiene nada que ver con la interface que hemos implementado anteriormente.
Por último, para terminar nuestro programa, nos falta crear nuestro punto de entrada.
 

public class Sistema {

	public static void main(String[] args) {
		
		Persona persona = new Persona();
		Perro perro = new Perro();
		
		Facade fachada = new Facade();
		fachada.correr(persona);
		fachada.correr(perro);
		
	}

}

 
Instanciamos un objeto de cada una de nuestras clases Persona y Perro. A continuación instanciamos la clase Facade, y le pasamos cada una de las instancias anteriores como argumento de su método “correr”, que como ya sabemos está esperando un objeto que implemente la interfaz Corredor.
Compilamos y tenemos la siguiente salida:
 

salida por consola

salida por consola


 
Vemos que, efectivamente, ha respondido el método “correr” de cada una de las clases. De esta forma, si mañana nos piden implementar una nueva clase Gato, no tendremos que tocar absolutamente nada del código que ya tenemos hecho. El sistema seguirá funcionando exactamente igual. Tan solo crearemos nuestra clase Gato implementando la interfaz Corredor, y declararemos aquello que nuestro Gato queramos que haga en su método “correr”. Así de sencillo.
Espero que el ejemplo, aunque muy simple, haya dejado claro las virtudes y beneficios de usar polimorfismo en nuestras aplicaciones.
Un saludo.-

Diseño de aplicaciones

Inyección de dependencias

Uno de los pilares de la programación orientada a objetos es la búsqueda del bajo acomplamiento entre las clases. Con esto entendemos que cualquier dependencia que una clase tenga sobre otra, en un futuro va a resultar en un problema a la hora de la escalabilidad y extensibilidad de la aplicación.
Para resolver dicho problema contamos con el patrón llamado inyección de dependencias (Dependency injection en inglés). En proyectos pequeños es posible que el uso de dicho patrón no sea necesario, pero en el caso de proyectos medianamente grandes, recurrir a él va a ser imprescindible. El problema en estos casos no es tanto saber qué es la inyección de dependencias sino cuándo, cómo y dónde implementarlo.
Así pues, vamos a ver un ejemplo muy sencillo donde voy a tratar de explicarlo.
Supongamos que tenemos un hardware cualquiera, el cual espera de un componente, desarrollado por un proveedor cualquiera, para poder funcionar. Imaginemos que, en un principio, disponemos de dos componentes distintos, los cuales trabajan de forma diferente para proveer al hardware de diversas funcionalidades. Con este punto de partida, lo primero que se nos ocurriría sería crear una clase Hadware que en su interior instanciara un objeto de un componente u otro según el caso. Hasta ahí bien. Pero, ¿qué ocurriría si mañana disponemos de mil componentes? Si además nos encontramos con que los componentes pueden cambiar la forma de hacer las cosas, la mantenibilidad se vería en entredicho. Tendríamos que modificar código practicamente en todo el programa, incluída por supuesto la clase Hardware. Queda claro que no es viable, que el diseño de la aplicación no es ni mucho menos elegante, y que no se respetan los principios de la programación orientada a objetos.
Dicho esto veamos cómo acometer este problema usando, evidentemente, la inyección de dependencias.
Primero crearemos una interface.
 

public interface Hardware {
	void Initialization();
	void Shutdown();
	void Prepare();
	void DoIt();
}

 
Esta interface contiene los cuatro métodos que el Hardware ha declarado para poder funcionar. Dichos métodos tendrán que ser implementados obligatoriamente por cualquier componente con el que vaya a interactuar. Crearemos ahora esos componentes que implementarán la interface.
 

public class ComponenteA implements Hardware{
	
	public void Initialization() {
		
		System.out.println("Iniciando... (componente A)");
		
	}

	public void Shutdown() {
		
		System.out.println("Apagando... (componente A)");
		
	}

	public void Prepare() {
		
		System.out.println("Preparando... (componente A)");
		
	}

	public void DoIt() {
		
		System.out.println("Trabajando... (componente A)");
		
	}

}

 

public class ComponenteB implements Hardware{

	public void Initialization() {
		
		System.out.println("Iniciando... (componente B)");
		
	}

	public void Shutdown() {
		
		System.out.println("Apagando... (componente B)");
		
	}

	public void Prepare() {
		
		System.out.println("Preparando... (componente B)");
		
	}

	public void DoIt() {
		
		System.out.println("Trabajando... (componente B)");
		
	}

}

 
Como podemos ver, he puesto una simple salida por consola en cada método para poder probar su funcionamiento.
Ahora, para que el cliente no acceda directamente a la lógica de negocio, crearemos una clase “fachada” usando el patrón Facade. Esto hará que el cliente interactue con él, ocultando toda la “sala de máquinas” de nuestro programa.
 

public class ProductFacade {

	private Hardware SomeHardware;
	
	public ProductFacade(Hardware SomeHardware)
	{
		this.setSomeHardware(SomeHardware);
	}

	public Hardware getSomeHardware() {
		return SomeHardware;
	}

	public void setSomeHardware(Hardware someHardware) {
		SomeHardware = someHardware;
	}	
	
}

 
Veamos esta última clase con detenimiento.
Declaramos una variable de tipo Hardware privada (encapsulamiento ante todo). Seguidamente tenemos el constructor que espera recibir un objeto de tipo Hardware, es decir, de cualquier clase que implemente la interface Hardware que hemos declarado al principio. Seguidamente terminamos con los getter y setter correspondientes, que nos permitirán acceder al objeto en cuestión y a todos sus métodos.
Ya solo nos queda implementar el punto de entrada, aquel que ejecutará el cliente.
 

public class Main {

	public static void main(String[] args) {

		Hardware componentA = new ComponenteA();
		ProductFacade product01 = new ProductFacade(componentA);
		product01.getSomeHardware().Initialization();
		product01.getSomeHardware().Prepare();
		product01.getSomeHardware().DoIt();
		product01.getSomeHardware().Shutdown();		
		
		Hardware componentB = new ComponenteB();
		ProductFacade product02 = new ProductFacade(componentB);
		product02.getSomeHardware().Initialization();
		product02.getSomeHardware().Prepare();
		product02.getSomeHardware().DoIt();
		product02.getSomeHardware().Shutdown();	

	}

}

 
Como podemos ver, instanciamos un objeto del componenteA y posteriormente se lo pasamos directamente al constructor de la instanciación de nuestra clase “fachada”. A partir de ahí ya podremos acceder a los métodos del componente inyectado a través de su getter.
A efectos prácticos, he instanciado los dos componentes consecutivamente para que podamos comprobar por consola cómo se comporta nuestro programa en cada momento.
Si ejecutamos el proyecto, la salida será la siguiente:
 

Salida por consola

Salida por consola


 
Las ventajas de usar este patrón son evidentes. A partir de ahora, si tenemos más componentes, no nos importará. Tan solo deberemos inyectar en cada momento el componente deseado a la clase “fachada” del método main. En el caso de que algún componente cambiara su funcionalidad, solo deberiamos efectuar los ajustes correspondientes en el método o métodos de su clase, sin tocar nada de código exterior a ella.
Mínimo esfuerzo en una aplicación escalable y mantenible. Eso es lo bueno de trabajar correctamente con la programación orientada a objetos.
Un saludo.-

A continuación vamos a ver, mediante una sencilla aplicación, un buen ejemplo de las posibilidades que puede proporcionarnos esta magnífica funcionalidad que trae consigo el estándar HTML5. Dicha aplicación consistirá en la posibilidad de votar nuestras redes sociales favoritas, haciendo uso, claro está, de la operación arrastrar y soltar.
Empecemos con el código html:

<body>
	
	<div id="header">
		<img id="cabecera" src="img/cabecera.png" />
		<h2>Vota tus aplicaciones favoritas</h2>
	</div>
		
	<hr>
		
	<div id="containerVotacion">
			
		<div id="Muy_buena" class="destino verde" ondrop="drop(event)" ondragover="allowDrop(event)" ondragleave="dragLeave(event)">
			<p>Muy buena</p>
		</div>
				
		<div id="Buena" class="destino amarillo" ondrop="drop(event)" ondragover="allowDrop(event)" ondragleave="dragLeave(event)">
			<p>Buena</p>
		</div>
				
		<div id="Regular" class="destino rojo" ondrop="drop(event)" ondragover="allowDrop(event)"	ondragleave="dragLeave(event)">
			<p>Regular</p>
		</div>
			
	</div>
		
	<div id="containerElementos" ondrop="drop(event)" ondragover="allowDrop(event)"	ondragleave="dragLeave(event)">
			
		<img id="facebook" src="img/facebook.png" draggable="true" ondragstart="drag(event)" ondragend="dragEnd(event)" width="64" height="64"/>
		
		<img id="twitter" src="img/twitter.png" draggable="true" ondragstart="drag(event)" ondragend="dragEnd(event)" width="64" height="64"/>
				
		<img id="linkedin" src="img/linkedin.png" draggable="true"	ondragstart="drag(event)" ondragend="dragEnd(event)" width="64" height="64"/>
			
	</div>
		
	<footer id="pie">
		<button id="resultados" onclick="obtenerResultados();">Ver resultados</button>
	</footer>
		
</body>

 

Aquí podemos observar tan solo la parte del “body” del html, para no distraernos con otras líneas de código que ahora no importan.
La imagen dentro del primer div simplemente aparece a modo decorativo. Todos los recursos que se emplean aquí van a estar disponibles a través del enlace a mi repositorio Github que os dejaré al final del artículo.
Vamos a fijarnos en lo importante. Hay dos div contenedores que van a diferenciar la zona disponible para votar, de la que contendrá los iconos de las redes sociales más relevantes, y que estarán disponibles parar ser arrastrados y soltados en la zona de votación que deseemos.
Así pues queda claro que el div con id containerVotación integra a los tres div que equivalen a las votaciones “muy buena”, “buena” o “regular”. Podemos observar que todos estos div tienen tres eventos in line. Veamos qué hacen:

  • ondrop: Controla si en el div se han “soltado” elementos con la propiedad draggable (que pueden ser arrastrados) sobre él. Esto, evidentemente, determina que se trata de una zona drop válida que permite alojar esos elementos provenientes de un drag (“arrastre”). Al hacerlo llamará a la función drop, pasándole como argumento el propio evento.
  • ondragover: Controla que en el div se están arrastrando elementos con la propiedad draggable hacia una zona que permita “soltar” esos elementos. Al hacerlo llamará a la función allowDrop, pasándole como argumento el propio evento.
  • ondragleave: Controla el momento en que un elemento draggable abandona la zona drop donde se encuentra.

El div con id containerElementos dispone de los mismos eventos arriba mencionados. Esto permite que de él se puedan tanto arrastrar como soltar elementos, lo mismo que ocurre con los div contenidos en el div contenedor containerVotación de forma individual.

En su interior cuenta con tres imágenes que se encargan de mostrar los logos de las tres redes sociales más relevantes del momento, las cuales tienen un id correspondiente a la red social en cuestión, y cuyos eventos pasamos a comentar:

  • draggable: Permite que el elemento puede ser “arrastrado” hacia una zona drop válida. Como vemos, se trata de una propiedad que únicamente hay que igualar a true para que funcione sobre el elemento donde estemos declarándola.
  • ondragstart: Este evento se dispara cuando el elemento comienza a ser “arrastrado” desde una zona drop válida.
  • ondragend: El evento se dispara cuando el usuario finaliza el “arrastrado” del elemento sobre una zona drop válida.

Con todo esto, y resumiendo, lo que tenemos es una zona que contiene elementos “arrastrables” y que, a su vez, permite depositar elementos “arrastrados” a nivel general. Lógicamente se trata del div containerElementos y sus img correspondientes. Por otro lado tenemos la zona que contiene a su vez zonas individuales que permiten igualmente depositar elementos “arrastrados” o que se “arrastren” a partir de ellos. Se trara del div containerVotacion y sus correspondientes div con id igual al tipo de nota que queremos otorgar al elemento draggable en cuestión.

Para finalizar, tenemos en el pie de página un botón que será el encargado de obtener los resultados de la votación.

Veamos ahora el código javascript encargado de toda la funcionalidad:

var destino;
var arrastrando;
var ancho;
var alto;
var resultado=new Array();
var resultadoFinal=new Array();

function allowDrop(ev)
{
ev.preventDefault();
destino = devuelveElemento(ev);
destino.style.opacity="0.4";
}

function drag(ev)
{
arrastrando = devuelveElemento(ev);
ancho = arrastrando.width;
alto = arrastrando.height;
arrastrando.style.width=ancho/2+"px";
arrastrando.style.height=alto/2+"px";
var dragIcon = document.createElement('img');
dragIcon.src = 'img/vote.png';
dragIcon.width = 100;
ev.dataTransfer.setDragImage(dragIcon, -10, -10);
ev.dataTransfer.setData("Text", ev.target.id);
}

function dragLeave(ev){
destino.style.opacity="1";
}

function dragEnd(ev){
arrastrando.style.width=ancho+"px";
arrastrando.style.height=alto+"px";
}

function drop(ev)
{
var contenedorUsado = destino.id;
var elementoVotado = arrastrando.id;
resultados(contenedorUsado,elementoVotado);
ev.preventDefault();
destino.style.opacity="1";
var data = ev.dataTransfer.getData("Text");
ev.target.appendChild(document.getElementById(data));
}

function devuelveElemento(ev){
var elemento = document.getElementById(ev.target.id);
return elemento;
}

function resultados(voto,votado){
resultado.push(voto+" "+votado);
}

function obtenerResultados(){

resultadoFinal = sanearResultados();

var ancho= 700;
var alto = 500;
var posicion_x;
var posicion_y;
posicion_x=(screen.width/2)-(ancho/2);
posicion_y=(screen.height/2)-(alto/2);
MiVentana = window.open("","Resultados Drag&Drop HTML5","toolbar=no, location=no, status=no, resizable=no, top="+ posicion_y +", left="+ posicion_x +", width=700, height=500");
MiVentana.document.write('<!DOCTYPE html>\n<head>\n<title>Resultados Drag&Drop HTML5</title>');
MiVentana.document.write('\n<meta charset="utf-8"/>');
MiVentana.document.write('\n<link href="http://fonts.googleapis.com/css?family=Yanone+Kaffeesatz:400,300,200,700&subset=latin,latin-ext" rel="stylesheet" type="text/css">');
MiVentana.document.write('\n<link rel="stylesheet" type="text/css" href="css/estilo.css"/>');
MiVentana.document.write('\n</head>\n<body>\n<div id="header">');
MiVentana.document.write('\n<img id="cabecera" src="img/cabecera.png" />');
MiVentana.document.write('\n<h2>Resultados</h2>\n');
for (var z=0;z<resultadoFinal.length;z++){
MiVentana.document.write(resultadoFinal[z]+"<br>\n");
}
MiVentana.document.write('<br>');
MiVentana.document.write('\n<input type="button" value="Cerrar" onclick="window.close()">');
MiVentana.document.write('\n</div>\n</body>\n</html>');
MiVentana.document.close();
}

function sanearResultados(){

var social = [];
var controlFacebook=0;
var controlTwitter=0;
var controlLinkedin=0;

for (var j=1;j<=resultado.length;j++){

var elemento = resultado[resultado.length-j].toString();

if (elemento.indexOf("Elementos")>0){
continue;
}

if (elemento.indexOf("facebook")>0 && controlFacebook==0){
social.push(elemento);
controlFacebook = 1;
}
if (elemento.indexOf("twitter")>0 && controlTwitter==0){
social.push(elemento);
controlTwitter = 1;
}
if (elemento.indexOf("linkedin")>0 && controlLinkedin==0){
social.push(elemento);
controlLinkedin = 1;
}

}

return social;
}

 
Bien, vayamos por partes.
Al principio declaramos unas cuantas variables a nivel global. Dos de ellas arrays.
Todas las funciones que se llaman cuando se desencadena algún evento ya visto, tienen como parámetro ev, es decir, el propio origen del evento mismo.

La función allowDrop, que se dispara cuando un elemento draggable pasa por una zona drop válida, lo que hace es guardar en la variable destino cuál es el elemento (en nuestro caso un div) sobre el que se está arrastrando un elemento draggable (en nuestro caso los img). Para ello se llama a la función devuelveElemento pasándole a su vez el origen del evento recibido. También damos una opacidad para que el contenedor drop disponible sobre el que se pasa, nos informe de que está listo para recibir el elemento draggable.

La función drag se dispara cuando un elemento draggable comienza a ser “arrastrado”. Para conocer de cúal se trata aprovechamos de nuevo la función devuelveElemento y lo guardamos en la variable creada para ello. Seguidamente hayamos su alto y ancho para asignarle la mitad de ambos durante el efecto de “arrastrado”. Además, creamos dinámicamente un pequeño icono bajo el elemento “arrastrado” para indicar al usuario que se está llevando a cabo el proceso. Para añadirlo definitivamente a nuestro elemento en proceso de “arrastrado”, debemos llamar al método dataTransfer, primero seteando su posición respecto al elemento “arrastrado” y después haciendo lo propio con el tipo de dato.

La función dragLeave se ejecuta cuando un elemento draggable deja de estar sobre una zona drop válida. En ese caso lo único que hacemos es eliminar la opacidad que tenga el contenedor drop sobre el que se acaba de terminar de pasar.

La función dragEnd devuelve el tamaño completo al elemento “arrastrado” cuando éste termina de “aterrizar” sobre una zona drop válida.

La función drop es llamada cuando una zona drop válida termina de recibir un elemento draggable. En ese momento obtenemos qué zona drop de nuestra aplicación está recibiendo el elemento y cuál es ese elemento (en nuestro caso el img de alguna red social). Esto ya lo sabemos gracias a las variables globales destino y arrastrando, que ya han guardado anteriormente esa información durante los pasos previos. Una vez los conocemos, llamamos a la función resultados pasándole esos datos. Lo que hace es añadirlos a un array, tal y como podemos comprobar un poco más abajo. Además eliminamos la opacidad de la zona drop y quitamos el icono que habíamos añadido para indicar que el elemento draggable estaba siendo arrastrado.
Finalmente, las funciones que nos quedan se van a encargar de obtener los resultados finales de la votación cuando pulsemos sobre el botón correspondiente.

La funcion obtenerResultados, que es la que se ejecuta al pulsar dicho botón, lo primero que hace es llamar al método sanearResultados. Dado que el usuario puede variar las veces que desee el elemento a votar por diferentes opciones drop, debemos tener en cuenta que, cada vez que lo haga, se registrará la votación dentro del array resultado visto anteriormente. Por esa razón debemos obtener siempre la última votación que haya recibido cada red social, ya que, como sabemos, un array siempre va guardando la información al final del mismo, a menos que no se le indique lo contrario. Así pues podemos ver que el bucle for comienza a recorrer el array por el final y va extrayendo la primera coincidencia que encuentra según el nombre de la red social. Todo ello se guarda en un nuevo array limpio de polvo y paja, y se devuelve como resultado.
Cuando se ha recuperado ese resultado desde la función obtenerResultados donde nos encontrábamos, lo único que hacemos es presentar una ventana flotante que mostrará finalmente, ahora sí, el resultado final, recorriendo para ello el nuevo array saneado que acabamos de recuperar.

Y eso es todo.

Quiero disculparme si la explicación es algo confusa, pero la verdad es que es algo complicado intentar plasmar a fondo línea a línea, qué es lo que hace cada una, sin ser algo redundante.
Recomiendo encarecidamente descargar la aplicación, probarla y, a continuación, con el código delante, volver a leer el artículo.
La aplicación completa cuenta con todos los recursos, fuentes y estilos, que terminan por otorgarle un buen aspecto final.

Descarga desde Github

Espero que este articulo os sirva para comprender un poco mejor cómo funciona esta maravillosa utilidad de HTML5 y, sobre todo, vislumbrar las infinitas posibilidades que nos puede ofrecer.
Gracias y un saludo.-

Capturas:

 

Drag&Drop

 

Drag&Drop

 

Drag&Drop

Desde hace algún tiempo he comprobado que hay muchos desarrolladores que al tratar de implementar un sistema de autenticación en CakePHP con AuthComponent tienen problemas y no funciona como debería. Sea por motivos de versión del framework o, simplemente, porque no está bien implementado el código, la cuestión es que la aplicación no funciona.
Vamos entonces a ver a continuación cómo programar un sistema de autenticación sin la necesidad del AuthComponent.
Partimos de que tenemos una base de datos conectada correctamente a través de la configuración de nuestro archivo database.php y, además, suponemos que tenemos ya una aplicación en CakePHP que debemos proteger de usuarios no autenticados.
Con lo primero que debemos contar es con una tabla en nuestra base de datos que yo he llamado users. Esta tabla cuenta a su vez con tres campos: id, username y password. El campo id será nuestra clave primaria autoincremental y los otros dos campos de tipo varchar.
Una vez hecho esto, vamos con el código. Abrimos nuestro archivo AppController que se encuentra en la ruta CarpetaAplicacion/app/Controller donde CarpetaAplicacion es el nombre de la carpeta donde guardas tu proyecto. Escribimos el siguiente código:

<?php

App::uses('Controller','Controller');

class AppController extends Controller {

public$components=array('Session');

    // Comprobar si el usuario está logueado
    function authenticate()
    {
        // Comprobamos si la variable de sesión existe. Si es así quiere decir que el usuario se ha logueado
       //correctamente y se le redirecciona a la aplicación.
      //Si no existe se le devuelve al login.
        if(!$this->Session->check('User'))
        {
            $this->redirect(array('controller'=>'users','action'=>'autenticar'));
            exit();
        }

    }
 
    //Autenticación obligatoria si se quiere entrar a cualquier parte de la aplicación
    function afterFilter()
    {
        if($this->action!='autenticar')
        {
            $this->authenticate();
        }
    }
}

La función afterFilter va a permitirnos controlar cuándo un usuario intenta entrar en una zona donde se ejecuta una acción distinta a ‘autenticar’. Inmediatamente llama a la función authenticate que nos va a permitir saber si se ha creado ya una sesión de usuario. Si es así significará que el usuario esta autenticado, con lo que automáticamente será redireccionado al index de la aplicación. Si no es así se le redireccionará de nuevo a la acción autenticar del controlador users (lo veremos a continuación) que, por supuesto, contará con una vista que contendrá el formulario de login. Sigamos.
Ahora vamos a crear, dentro de la carpeta de nuestros modelos, un archivo con el nombre User.php. La ruta será CarpetaAplicacion/app/Model/User.php. Escribimos lo siguiente:

<?php
App::uses('AppModel','Model');
/**
 * User Model
 *
 */
class User extends AppModel {

   var$name='User';

/**
 * Display field
 *
 * @var string
 */

   public$displayField='username';

   var$validate=array(
       'username'=>array(
                    'rule'=>array('minLength',1),
                    'required'=>true,
                    'allowEmpty'=>false,
                    'message'=>'Por favor, introduce un nombre'
                    ),
       'password'=>array(
                    'rule'=>array('minLength',1),
                    'required'=>true,
                    'allowEmpty'=>false,
                    'message'=>'Por favor, introduce la contraseña'
                    ),

   );

}

Lo que hemos hecho es crear nuestra clase modelo que conectará con nuestra tabla users de la BD. También usamos la validación de los campos username y password del formulario que posteriormente crearemos en nuestra View.
Continuamos. Volvemos a nuestra carpeta de controladores y creamos un archivo llamado UsersController.php. La ruta será CarpetaAplicacion/app/Controller/UsersController.php. Aquí escribimos ahora el siguiente código:

<?php
App::uses('AppController','Controller');
/**
 * Users Controller
 *
 * @property User $User
 * @property PaginatorComponent $Paginator
 */
class UsersController extends AppController {

/**
 * Components
 *
 * @var array
 */
    public$components=array('Session');
 
    publicfunction autenticar(){
        // Aunque los campos username y password tienen validación para que no estén vacíos,
// volvemos a asegurarnos con el condicional que el campo username del formulario tiene
        //algún valor
        if(empty($this->data['User']['username'])==false)
        {
    	 //Consulta SQL para buscar al usuario con sus credenciales en la BD
$user=$this->User->find('all',array('conditions'=>array(
                'User.username'=>$this->data['User']['username'],
                'User.password'=>$this->data['User']['password'])));
         //Si se ha encontrado al usuario en la consulta
         if($user!=false)
         {
          //Si existe se redirecciona al usuario a la aplicación creando una variable de sesión 
          $this->Session->setFlash(__('Gracias por loguearse!'));
          $this->Session->write('User',$user);
          $this->Redirect(array('controller'=>'ControllerDeTuAplicacion','action'=>'index'));
          exit();
         }
         else
         {
//Si los datos no son correctos se comunica al usuario y se le devuelve al mismo
          //formulario de login
          $this->Session->setFlash(__('Nombre de usuario y/o password incorrectos'));
          $this->Redirect(array('action'=>'autenticar'));
          exit();
         }
        }
    }
}

Veamos qué hace nuestra clase controller. Es imprescindible, como en el archivo AppController, tener cargado el componente Session. Como podemos ver lo tenemos en nuestra variable pública $components. Lo primero que va a hacer la clase es comprobar que se han pasado datos en el campo username desde el formulario. Es cierto que los campos ya están validados desde nuestro Model, pero siempre es interesante comprobarlo también aquí. Si no es correcto, es decir, si el campo está vacío, entonces se redirecciona de nuevo al mismo formulario. De esto se encarga nuestro Model como sabemos, ya que al no haber ninguna variable Session creada reaccionará en consecuencia. Si, por el contrario, hay datos, se ejecuta una consulta en la BD para comprobar que, efectivamente, el usuario y password existen. Si no existen, entonces se le redireccciona al usuario de nuevo a la acción autenticar que hará que nuestro afterFilter del archivo AppController (¿Recuerdas?) compruebe que exista una variable de sesión. Como no es así se le reenvía automáticamente de nuevo al formulario con un mensaje flash indicando que uno o los dos campos no son correctos. Si existe el usuario, entonces se le redirecciona a la página index de la aplicación, no sin antes crear la variable de sesión que nos permitirá superar con éxito el método authenticate de nuestro AppController que es llamado automáticamente desde nuestro vigilante afterFilter.
Ya lo único que nos queda es crear nuestra View que mostrará el formulario para poder loguearse. Vamos a la ruta CarpetaAplicacion/app/View y creamos la carpeta Users. Despues, dentro de ella, creamos el archivo autenticar.ctp con el siguiente código:

<div>
<?php echo $this->Form->create('User'); ?>
	<fieldset>
		<legend><?php echo __('Login aplicación'); ?></legend>
	<?php
		echo $this->Form->input('username');
		echo $this->Form->input('password');
	?>
	</fieldset>
<?php echo $this->Form->end(__('Continuar')); ?>
</div>

Como se puede observar se trata de un simple formulario muy sencillo donde no creo que haya nada que explicar. Pues ya está, con esto hemos terminado. Ahora tenemos un sistema que permite proteger el acceso a nuestra aplicación de todos aquellos usuarios que, previamente, no estén en la base de datos. Obviamente, para poder probarlo, necesitamos entonces tener al menos un usuario en nuestra tabla users. Este ejemplo no contempla la posibilidad de registrarse pero creo que, con este punto de partida, no es nada complicado implementarlo. Pero eso lo dejo para vosotros 🙂 Un saludo.-