Temas

[TimerTask]

La clase Timer es una clase muy útil para situaciones particulares. Estas situaciones pueden ser por ejemplo, cuando necesitamos hacer algo cada X tiempo. Quizás hayas visto en algunas webs que aparecen ofertas o anuncios cada X tiempo, pues bien, esto se hace gracias a los Timers.

Vamos a realizar un pequeño timer que hace un conteo regresivo imprimiendo en pantalla la hora actual. Primero hagamos una clase que muestre la hora actual.

Código (java) [Seleccionar] Expandir


public class Display {

    public void printTime(int hour, int minute, int second) {
        String fullHour = "";

        fullHour += (hour > 9) ? ":" + hour : "0" + hour;
        fullHour += (minute > 9) ? ":" + minute : ":0" + minute;
        fullHour += (second > 9) ? ":" + second : ":0" + second;

        System.out.println(fullHour);
    }
}

Nada del otro mundo, solo le da formato a una hora recibida como 3 parámetros: hora, minuto y segundo. Esta clase la usaremos en el Timer para mostrar la hora actual.

Código (java) [Seleccionar] Expandir


import java.util.Timer;
import java.util.TimerTask;

public class Timeout {

    private int hour = 0;
    private int minute = 0;
    private int second = 11;
    private Timer timer;
    private boolean isTimerRunning;
    private Display display;

    public Timeout() {
        timer = new Timer();
        display = new Display();
    }

    TimerTask task = new TimerTask() {
        @Override
        public void run() {
            isTimerRunning = true;
            if(second > 0) {
                second--;
            } else {
                second = 59;
                if(minute > 0) minute--;
                else {
                    minute = 59;
                    if(hour > 0) hour--;
                    // si segundo = 0, minuto = 0 y hora = 0,
                    // cancelamos el timer
                    else {
                        isTimerRunning = false;
                        timer.cancel();
                        timer.purge();
                    }
                }
            }
            if(isTimerRunning)
                display.printTime(hour, minute, second);
        }
    }; // fin timertask

    public void start(int timeout, int interval) {
        timer.schedule(task, timeout, interval);
    }

} // fin clase

El código es autoexplicado. En lo que debemos de fijarnos es el TimerTask. La TimerTask nos permite realizar tareas en un thread separado. Esto es así, porque por lo general, cuando usamos un Timer es para que se esté ejecutando cada cierto tiempo un código de forma paralela, esto eso, multithreading programming (programación multi hilo). El código del TimerTask solo hace una serie de comprobaciones para disminuir la hora, minuto y segundo. Luego, llama al método printTime del objeto Display, pasándole la hora, minuto y segundo y que este método dará forma e imprimirá.

Para empezar un timer, debemos de llamar al método schedule el cual recibe 3 parámetros:

• Un objeto TimerTask
  
• Un timeout (tiempo de espera para que empiece a ejecutarse)
  
• Un intervalo (la tarea se ejecutará cada X tiempo)
  
  Los dos últimos parámetros se debe especificar en milisegundos, así, 1000 es equivalente a 1 segundo. Por último, hagamos nuestra clase principal.
  
  
  Código (java) [Seleccionar] Expandir
  
public class TimerTest {

    public static void main(String[] args) {
        Timeout timeout = new Timeout();
        timeout.start(0, 1000);
    }
}
  
  En la clase principal decimos que el timer tendrá un delay de 0s y un intervalo de 1s. Si compilamos y corremos:
  
  
  Código (dos) [Seleccionar] Expandir
  javac Display.java
javac Timeout.java
javac TimerTest.java

java TimerTest
  
  Obtendremos lo siguiente:
  
  
  
  
  
  ¿Posibilidades? La que puedas imaginar, así que piensa como sacarle provecho en tu próximo proyecto.

[CDI]

CDI

Context and Dependency Injection o Contexto e inyección de depencias en español, es un poderoso elemento de la plataforma Java EE el cual nos provee un poderoso mecanismo de inyección de depencias. Además, nos provee de muchas utilidades, como interceptores, calificadores, eventos, decoradores, productores y trituradores, entre otros.

CDI es un concepto incomprendido por gran parte de los programadores Java EE. En el presente documento, intentaremos despejarnos las dudas. Empecemos.


Dependency Injection

Dependency Injection (DI) es un patrón de diseño que desacopla componentes depenientes. Es parte de inversion of control (IoC) donde el objetivo que es invertido es el proceso de obtención de dependencias necesarias. El término fue originalmente dicho por Martin Fowler. Una manera de pensar en DI en un entorno manejado como Java EE es pensar en JNDI al revés. En lugar que un objeto busque por otros, el contenedor inyecta su dependencia por ti. Esto es llamado Principio Hollywood, "Don't call us (buscar objetos), we'll call you (inyectar objetos)".


Gestión del ciclo de vida

El ciclo de vid de un POJO es muy simple, creas una instancia de una clase usando la palabra reservada new y esperas a la recolección de basura para que la elimine y libere algo de memoria. En su lugar, necesitas inyectar el bean y el contenedor hace el resto, esto quiere decir que el contenedor es el único responsable de gestionar el ciclo de vida de un bean: este lo crea, este lo destruye. Así que, ¿como inicializas un bean si tu no llamas a un constructor? El contenedor te brinda un manejo luego de construir la instancia y antes de destruirla. Estas anotaciones son:

• @PostConstruct: un método anotado con esta anotación es llamado inmediatamente después que el contenedor haya inyectado el bean (instanciado).
• @PreDestroy: un método anotado con esta anotación es llamado justo antes que el recolector de basura elimine el bean.

CDI Bean

Un bean CDI puede ser cualquier tipo de clase que contenga lógica de negocio. Este puede ser llamado directamente por código Java vía inyección o puede ser invocado vía El desde una página JSF. Un bean es un POJO que no extiende de nada, puede inyectar referencias en otros beans (@Inject), tiene su ciclo de vida manejado por el contenedor y puede tener sus propios metodos incerptores:

Código (java) [Seleccionar] Expandir

public class BankLoan {
    @Inject
    private AccountChecker accountChecker;
    private Date dateOfLoan;

    @PostConstruct
    private void initializeDate() {
        dateOfLoan = new Date();
    }
}

En el ejemplo anterior, se está inyectando la dependencia del bean accountChecker, esto lo hace el contenedor. El método initializeDate anotado con @PostConstruct será llamado automáticamente luego de que se instancie la clase BankLoan. Los CDI beans tienen ciertas características que deben cumplirse de manera obligatoria. Estas son:

• No debe ser una interna no estática.
  
• Tiene un constructor por defecto sin parámetros o debe declarar un constructor anotando @Inject.
  
• Es una clase concreta (no debe extender) o  es anotada con @Decorator
  
  Para mayor comprensión, veamos el siguiente diagrama de clases:
  
  
  
  
  ¿Cómo conectamos CDStore y CreditCard? La forma que todos conocemos es mediante el operador new:
  
  
  Código (java) [Seleccionar] Expandir
  public class CDStore {
    private CreditCard creditCard;
   
    public CDStore() {
        creditCard = new Visa();
    }
    public void buyItems() {
        // pagar con la tarjeta
  creditCard.pay();
    }
}
  
  El código anterior es bien simple  y es lo que nosotros hacemos y conocemos. Pero, ¿que pasaría si quisieras pagar con MasterCard?, ¿Necesitarías crear una (otra) instancia de MasterCard? Una solución pasar su dependencia por medio del constructor de una clase externa que haga uso de la clase CDStore:
  
  
  Código (java) [Seleccionar] Expandir
  public class CDStore {
    private CreditCard creditCard;

    public CDStore(CreditCard creditCard) {
        this.creditCard = creditCard;
    }
    ...
}
  
  En otra clase:
  
  
  Código (java) [Seleccionar] Expandir
  CDStore cdStore = new CDStore(new MasterCard());
  
  Ésto es lo que se conoce como inversion of control (IoC) o inversión de control (en español). La dependencia se inyecta desde una tercera clase, de ésta manera no creamos un vínculo entre CDStore y CreditCard.
  
  Inyección (@Inject)
  
  Java EE es un entorno gestionado, así que quizás no necesitas construir las dependencias tú mismo, en su lugar, puedes dejar que el contenedor inyecte las dependencias de los beans por tí. CDI tiene la habilidad de inyectar dependencias de prácticamente lo que sea. Veamos un ejemplo:
  
  
  Código (java) [Seleccionar] Expandir
  public class CDStore {
    @Inject
    private CreditCard creditCard;
   
    public void buyItems() {
        creditCard.pay();
    }
    ...
}
  
  Como se puede observar, no necesitamos construir la dependencia de creditCard, se lo dejamos al contenedor. La implementación se vería así:
  
  
  Código (java) [Seleccionar] Expandir
  public class Visa implements CreditCard {
    @Override
    public void pay() {
         // logica de negocio
    }
}
  
  Nota que solo hemos especificado una implementación de la interface CreditCard. Si hubiéramos creado otra implementación, la inyección no se podría realizar porque el contenedor no sabría qué dependencia inyectar. Esto, lo resolveremos más adelante con calificadores (@Qualifier).
  
  
  
  ANEXO
  
  Puntos de inyección
  
  Una inyección puede llevarse a cabo en tres puntos:
  
  
• Por propiedad:
  
     
  Código (java) [Seleccionar] Expandir
  @Inject
private CreditCard creditCard;
  
     Nota que no es necesario especificar setter para la propiedad.
  
• Por constructor:
  
     
  Código (java) [Seleccionar] Expandir
  @Inject
         private CDStore (CreditCard creditCard) {
             this.creditCard = creditCard;
        }
  
     La regla aquí es que la inyección por constructor se puede realizar solo una vez (por    clase).
  
  
• Por setter:
     
  Código (java) [Seleccionar] Expandir
  @Inject
        public void setCreditCard(CreditCard creditCard) {
            this.creditCard = creditCard;
        }
  
  
  Ésto es un anexo, porque en realidad no importa en qué punto hagas la inyección. Por propiedad, constructor o setter, para el contenedor le da igual. Por lo tanto, escoger uno u otro, es simplemente opción personal.
  
  
  
  Injección por defecto (@Default)
  
  Tu puedes tener una dependencia para inyectar por defecto. Por ejemplo, nosotros tenemos solo una implementación, aquella, tendrá implícitamente el modificador @Default. Así, ésto:
  
  
  Código (java) [Seleccionar] Expandir
  @Inject
private CreditCard creditCard;
  
  Es igual que:
  
  
  Código (java) [Seleccionar] Expandir
  @Inject @Default
private CreditCard creditCard;
  
  Podemos apreciarlo en una imagen:
  
  
  
  
  Si tienes una implementación, el contenedor inyectará la única dependencia existente. Si por otro lado, tienes muchas implementaciones de una interface, el contenedor no sabrá cuál implementación debe inyectar, y aquí es cuando toman tanta importancia los calificadores.
  
  
  Calificadores (@Qualifier)
  
  Cuando el sistema inicia, el contenedor CDI debe validar que todos los beans satisfasgan cada punto de inyección existente. Si alguna dependencia de un bean no puede ser satisfecha por el contenedor CDI, entonces la aplicación no se podrá desplegar informando de una insatisfacción de dependencia. Si hay una sola implementación disponible, la inyección funcionará aplicando la dependencia única, que es marcada implícitamente con @Default.
  
  Si hay más de usa implementación y tratamos de desplegar, la aplicación no desplegará porque dectectará ambiguación en las dependencias, es decir, si hay 2 o más implementaciones, ¿cómo sabe el contenedor qué dependencia inyectar? Aquí es donde toman importancia los calificadores. Veamos el siguiente diagrama de clases que ilustra la situación actual:
  
  
  
  
  Podemos ver que hemos creado una nueva implementación, llamada MasterCard, la misma está anotada bajo el calificador MasterCardPay. Además, vemos como una nueva clase, CDStoreWithQualifier inyecta la nueva dependencia. Esto lo hará mediante el calificador. Veamos el ejemplo en código (solo las nuevas clases):
  
  Calificador MasterCardPay:
  
  
  Código (java) [Seleccionar] Expandir
  @Qualifier
@Retention(RUNTIME)
@Target({FIELD, TYPE, PARAMETER, METHOD})
public @interface MasterCardPay {}
  
  Implementación MasterCard:
  
  
  Código (java) [Seleccionar] Expandir
  @MasterCardPay
public class MasterCard implements CreditCard {
    private Logger logger = Logger.getLogger(MasterCard.class.getName());
   
    @Override
    public void pay() {
        logger.log(Level.INFO, "Pagando con MasterCard");
    }
}
  
  La anotación @Retention, especifica el nivel de retención de la anotación. Existen 3 tipos:
  
  
• SOURCE: la anotación será visible en el código fuente, una vez que se compila la aplicación, es descartada. La anotación no será escrita en bytecode. Por ejemplo, @Override.
  
• CLASS: La anotación se descarta durante la carga de la clase por parte del ClassLoader. Sí se escribe en bytecode.
  
• RUTNIME: No se descarta. Ésta anotación estará siempre disponible por reflection en tiempo de ejecución.
  
  Las primeras dos anotaciones no podrán ser inspeccionadas en tiempo de ejecución, mientras que la última sí. Esta es la diferencia entre las 3.
  La anotación @Target, especifica que elementos podrán ser afectados por la anotación. Hay varias opciones:
  
  
• ElementType.ANNOTATION_TYPE
  
• ElementType.CONSTRUCTOR
  
• ElementType.FIELD
  
• ElementType.LOCAL_VARIABLE
  
• ElementType.METHOD
  
• ElementType.PACKAGE
  
• ElementType.PARAMETER
  
• ElementType.TYPE
  
  Creo que la mayoría se explican solas. Las dos anotaciones que son un poco confusas son ANNOTATION_TYPE y TYPE. ANNOTATION_TYPE significa que la anotación solo podrá ser usada para anotar otras anotaciones, como @Retention. TYPE significa cualquier tipo de elemento (clases, interfaces, enums, anotaciones, etc).
  
  Comprendidos ya estos conceptos, vamos a ver la clase que inyecta la nueva implementación:
  
  
  Código (java) [Seleccionar] Expandir
  public class CDStoreWithQualifier {
    @Inject @MasterCardPay
    private CreditCard masterCard;
   
    public void buyItems() {
        masterCard.pay();
    }
}
  
  Observa lo sencillo que es inyectar múltiples dependencias, solo basta con indicar el calificador de la dependencia que debe ser inyectada. Es posible también anotar un elemento con múltiples anotaciones. Java no nos limita en este aspecto. Por ejemplo:
  
  
  Código (java) [Seleccionar] Expandir
  @Inject @Visa @Gold
private CreditCard creditCard;
  
  
  Productores (@Produces)
  
  Como ya hemos visto, podemos inyectar CDI beans dentro de otros CDI beans. Pero, si quisiéramos inyectar POJOs, o tipo de datos primitivos, ¿sería eso posible? La respuesta corta es no y la razón es la siguiente.
  
  Por defecto, no puedes inyectar clases como String o Date y la razón, es porque ellas están empaquetadas en el archivo rt.jar (Java runtime enviroment classes) y este no contiene un descriptor de beans beans.xml. Esto es importante tenerlo presente, si un archivo no tiene un descriptor beans.xml bajo el directorio META-INF, CDI no activará el descrubimiento de beans (bean discovery) y los POJOs no podrán ser tratados como beans y por ende, no podrán ser inyectados. Afortunadamente, podemos revertir esta situación con ayuda de los productores. Veamos un ejemplo:
  
  
  
  
  Veamos que la clase CDSerialProducer tiene 3 anotaciones, las cuales pasamos a describir:
  
  
• @Produces: utilizada para producir un bean listo para inyección.
  
• @CDSerialPrefix: anotación propia.
  
• @RandomNumber: anotación propia.
  
  Primer veamos nuestras anotaciones, serán igual que los calificadores que ya hemos visto:
  
  
  Código (java) [Seleccionar] Expandir
  @Retention(RUNTIME)
@Target({FIELD, TYPE, PARAMETER, METHOD})
public @interface CDSerialPrefix { }
  
  
  Código (java) [Seleccionar] Expandir
  @Retention(RUNTIME)
@Target({FIELD, TYPE, PARAMETER, METHOD})
public @interface RandomNumber { }
  
  Ahora, veamos como producimos beans para inyectar de tipo String e int:
  
  
  Código (java) [Seleccionar] Expandir
  public class CDSerialProducer {
    @Produces @CDSerialPrefix
    private final String prefix = "T9-SK534";
   
    @Produces @RandomNumber
    public int generateNumber() {
        return new Random().nextInt(10000);
    }
}
  
  La anotación @Produces, producirá una propiedad y un método para inyectar. Seguido de @Produces, debemos de especificar el calificador con el cual se va a inyectar la propiedad y el método. En este caso son @CDSerialPrefix y @RandomNumber. Ahora veamos como los inyectamos:
  
  
  Código (java) [Seleccionar] Expandir
  public class CDService {
    @Inject @CDSerialPrefix
    private String prefix;
    @Inject @RandomNumber
    private int number;
    private Logger logger = Logger.getLogger(getClass().getName());
   
    public void createCD() {
        logger.log(Level.INFO, "Creando CD con serial: {0}", (prefix + number));
    }
}
  
  Si ejecutamos el proyecto, podemos ver que se inyectan satisfactoriamente los valores de la propiedad y el método dentro de las propiedades de CDService. Gracias a los productores, podemos inyectar prácticamente lo que sea.
  
  
  
  ANEXO
  
  API de InjectionPoint
  
  Los atributos y propidades producidad por productores (@Produces) no necesitan saber ningún tipo de información acerca de donde ellos son inyectados. Sin embargo, hay ciertos casos  donde podría ser de utilidad que el bean a inyectar sepa en qué punto de inyección se ha llevado a cabo la inyección. Un ejemplo común de ésto, es generar una dependencia dinámica de Logger (para crear logs). Generalmente, siempre creamos un Logger así:
  
  
  Código (java) [Seleccionar] Expandir
  Logger logger = Logger.getLogger(TuClase.class.getName());
  
  Lo anterior funciona correctamente, pero también podríamos generar depenencias dinámicamente. Veamos primero la API de InyectionPoint:
  
  
  
  
  Podemos usar esta API para generar una dependencia dinámica para Logger. Veamos un ejemplo:
  
  
  Código (java) [Seleccionar] Expandir
  public class LoggerProducer {
    @Produces
    private Logger createLogger(InyectionPoint ip) {
        return Logger.getLogger(ip.getMember().getDeclaringClass().getName());
    }
}
  
  Perfecto. Ahora tan solo debemos inyectar al logger de ésta manera:
  
  
  Código (java) [Seleccionar] Expandir
  @Inject Logger log;
  
  ¿Cómo ocurre la magia? Bien, el contenedor CDI buscará cualquier bean de tipo Logger listo para inyectar, y lo encuentra gracias a que hemos anotado el método con @Produces, lo que deja ese método listo para su inyección (como con @CDSerialPrefix y @RandomNumber del ejemplo anterior).
  
  
  
  
  Trituradores (@Disposes)
  
  Ahora sabemos como producir beans o valores para inyectar, pero algunos beans podrían necesitar ser cerrados, como es el caso de conexiones JDBC o un EntityManager. Por lo tanto, algunos beans producidos deberían asegurarse de ser cerrados. Aquí es donde toman importancia los Disposers. Los Disposers son lo  contrario a Producers, éste último crea beans o valores para inyectar, mientras que el primero se encarga de destruirlo.
  Veamos un ejemplo con una clásica conexión JDBC:
  
  
  Código (java) [Seleccionar] Expandir
  public class DerbyJdbcProducer {
    private final static String DRIVER = "org.apache.derby.jdbc.EmbeddedDriver";
    private final static String URL = "jdbc:derby://localhost:1527/CDI";
    private final static String USER = "duke";
    private final static String PASS = "1234";
    @Inject
    private Logger logger;
   
    @Produces
    public Connection createConnection() {
        Connection con = null;
        try {
            Class.forName(DRIVER).newInstance();
            con = DriverManager.getConnection(URL, USER, PASS);
            logger.log(Level.INFO, "Creando conexión JDBC con Derby");
        } catch(InstantiationException | IllegalAccessException |
                ClassNotFoundException | SQLException e) {
            e.printStackTrace();
        }
        return con;
    }
    public void closeConnection(@Disposes Connection con) {
        try {
            con.close();
            logger.log(Level.INFO, "Cerrando conexión JDBC con Derby");
        } catch (SQLException e) {
            e.printStackTrace();
        }
    }
}
  
  Un método disposer debe obligatoriamente recibir un parámetro @Disposes y el tipo del parámetro debe ser el mismo que el tipo devuelto con el método productor (@Produces) y su calificador (@Qualifier) en caso haya más métodos productores con el mismo tipo de retorno. Dado que el ciclo de vida de un bean inyectado depende del contexto en donde se inyecta, cuando se elimina el bean que contiene el bean inyectado, éste se destruirá también. Pero si no hubiésemos escrito el método disposer, la conexión nunca se hubiese cerrado por ser ésta independiente del contexto. Cuando el bean que contiene el bean inyectado es eliminado, antes que eso ocurra, se ejecutará el método disposer del bean inyectado, en este caso, cerrando la conexión JDBC.
  
  
  
  ANEXO
  
  Alcances (scopes)
  
  Todo objeto cuyo ciclo de vida es manejado por CDI tiene un alcance definido y un ciclo de vida que está ligado a un contexto específico. En Java, el alcance de un POJO es muy simple: tu creas una instancia de una clase usando la palabra reservada new y tu confías en el recolección de basura para deshacerse  de él y liberar alguna memoria. Con CDI, un bean es ligado al contexto y este lo mantiene en ese contexto hasta que el bean es destruido por el contenedor. No hay manera para remover manualmente un bean desde un contexto.
  
  CDI define los siguientes alcances y permite puntos de extesión para crear tu propio alcance:
  
  
• Application scope(@ApplicationScoped): Se extiende por la duración entera de una aplicación. El bean es creado solo una vez por duración de la aplicación y es descartado cuando la aplicación se apaga. Este alcance es util para cases utilitarias o helpers, u objetos que guardan datos compartidos por la aplicación entera (pero deberías ser cuidadoso con los problemas de concurrencia cuando los datos tienen que ser accesados por muchos threads).
  
  
• Session scope(@SessionScoped): Se extiene a través de muchas peticiones HTTP o muchas invocaciones de métodos por una sola sesión de usuario. El bean es creado por la duración de una sesión HTTP y es descartado cuando la sesión termina. Este ámbito es para objectos que son necesarios a lo largo de la sesión como preferencias de usuario o credenciales de login.
  
  
• Request scope(@RequestScoped): Corresponde a una simple petición HTTP o a una invocación de un método. El bean es creado para la duración de una invocación a un métod y es descartado cuando el método termina. Esto es usado para clases de servicio o beans JSF que son solo necesitados durante la duración de una petición HTTP.
  
  
• Conversation scope(@ConversationScoped): Se extiende entre múltiples invocaciones dentro de los límites de una sesión con puntos de inicio y fin determinados por la aplicación. Este alcance es usado a través de múltiples páginas como parte de un flujo de trabajo de múltiplos pasos.
  
  
• Dependent pseudo-scope(@Dependent): El ciclo de vida es el mismo que del cliente. Un bean @Dependent es creado cada vez que este es injectado y la referencia es eliminada cuando el objetivo de la inyección es eliminado. Éste es el alcance por defecto para CDI.
  
  Como puedes ver, todos los alcances tienen una anotación que tu puedes usar en tus beans CDI (todas ellas están en el paquete javax.enterprise.context). Los primeros tres alcances son bien conocidos. Por ejemplo, si tu tienes un bean de alcance de sesión como de un carro de compras, el bean será automáticamente creado cuando la sesión inicia (primera vez que un usuario se loguea) y es  destruido automáticamente cuando la sesión termina.
  
  

  Notas: El ciclo de vida de un bean @Dependent está ligado al ciclo de vida del bean que lo contiene. Se crea cuando el bean que lo contiene es instanciado y es eliminado cuando el mismo es eliminado. Es el scope por defecto.

  
  
  Conversation (@ConversationScoped)
  
  El alcande conversation es un poco diferente al resto. Este alcance mantiene estados asociados en un intérvalo de tiempo, a través de múltiples peticiones y es eliminado programáticamente (explícitamente) por la aplicación. Este alcance es usado mayormente en procesos  donde se requiere mantener valores durante múltiples peticiones HTTP pero sin extenderse demasiado, como un alcance @SessionScoped.
  
  API de Conversation:
  
  
  
  
  La principal diferencia con otros alcances, es que ellos son eliminados automáticamente por el contenedor al cabo de un tiempo cuando termina la petición, sesión, aplicación, etc. En Conversation, nosotros debemos encargarnos terminar su ciclo de vida. Por ejemplo, un bean @ConversationScoped puede ser usado para un asistence de registro de usuario. Deseamos mantener los datos que se van registrando del usuario a través de distintas páginas y que elimine el bean al terminar el registro:
  
  
  Código (java) [Seleccionar] Expandir
  @Named
@ConversationScoped
public class UserRegistrationWizard implements Serializable {
    @Inject
    private Conversation conversation;
    @Inject
    private User user;
    @Inject
    private transient Logger logger;
   
    @PostConstruct
    public void init() {
        conversation.begin();
    }
    public User getUser() {
        return user;
    }
    public void register() {
        conversation.end();
        logger.log(Level.INFO, "Usuario registrado:");
        logger.log(Level.INFO, "Email: {0}", user.getEmail());
        logger.log(Level.INFO, "Password: {0}", user.getPassword());
        logger.log(Level.INFO, "Fecha Nacimiento: {0}", user.getBirthDate());
    }
}
  
  Para probarlo, crea distintas páginas JSF y en cada una pon un formulario con un input text para el email, un input secret para el password y un input text para la fecha de cumpleaños:
  
  start.xhtml
  
  
  Código (html5) [Seleccionar] Expandir
  <h3>Inicio de registro</h3>
        <h:form>
            <h:outputLabel for="email" value="Email:"/>
            <h:inputText id="email" value="#{userRegistrationWizard.user.email}"/>
            <h:commandButton value="Siguiente" action="step2"/>
        </h:form>
  
  step2.xhtml
  
  
  Código (html5) [Seleccionar] Expandir
  <h3>Paso 2</h3>
        <h:form>
            <h:outputLabel for="password" value="Contraseña"/>
            <h:inputSecret id="password" value="#{userRegistrationWizard.user.password}"/>
            <h:commandButton value="Siguiente" action="end"/>
        </h:form>
  
  end.xhtml
  
  
  Código (html5) [Seleccionar] Expandir
  <h3>Paso 3</h3>
        <h:form>
            <h:outputLabel for="birthDate" value="F. Nacimiento:"/>
            <h:inputText id="birthDate" value="#{userRegistrationWizard.user.birthDate}">
                <f:convertDateTime pattern="dd-MM-yyyy"/>
            </h:inputText>
            <h:commandButton value="Registrar" action="#{userRegistrationWizard.register()}">
                <f:ajax execute="@form" />
            </h:commandButton>
        </h:form>
  
  Al llegar a la últma página y pulsar el botón registrar, se ejecuta el método registrar(), donde termina la conversación y se imprime toda la información del usuario recolectada durante la misma.
  
  
  Interceptores (@Interceptor)
  
  Los interceptores te permiten agregar conceptos a través de tus beans. Cuando un cliente invoca a un método en un Managed Bean (y por lo tanto a CDI beans, EJB, RESTful, ...), el contenedor puede interceptar la invocación y procesar lógica de negocio antes que el método del bean sea invocado. Los interceptores vienen en cuatro tipos:
  
  
• Interceptores a nivel de constructor: el interceptor es asociado con un constructor de la clase objetivo (@AroundConstruct)
  
• Interceptores a nivel  de método: el interceptor es asociado con un método de negocio específico (@AroundInovke)
  
• Interceptores por tiempo límite: el interceptor se interpone en el tiempo límite de los métodos (@AroundTimeout (usado solo con EJB timer)
  
• Interceptores de ciclo de vida: el interceptor se interpone en las llamadas de eventos del ciclo de vida del objetivo (@PostConstruct y @PreDestroy).
  
  Un método anotado con @AroundInvoke, debe tener el siguiete patrón de firma:
  
  
  Código (java) [Seleccionar] Expandir
  @AroundInvoke
Object <Método> (InvocationContext ic) throws Exception;
  
  Las siguientes reglas aplican a un método @AroundInvoke:
  
  
• El método puede tener cualquier modificador de visibilidad pero no debe ser static o final.
  
• El método debe tener un parámeto InvocationContext y debe retornar Object, el cual es el resultado del método objetivo invocado.
  
• El método debe lanzar una excepción comprobada.
  
• El objeto InvocationContext permite a los interceptores controlar el comportamiento de la cadena de invocaciones. Si muchos interceptores son encadenados, la misma instancia de InvocationContext es pasada a cada interceptor, quien puede agregar datos contextuales para ser procesador por otros interceptores.
  
  Echememosle un ojo a la API de InvocationContext:
  
  
  
  
  Otra forma de trabajar con interceptores, es que estos pueden estar en una clase y luego ser referenciada por la clase que los necesite:
  
  
  Código (java) [Seleccionar] Expandir
  @Interceptors(MisInterceptores.class)
public class MiClase { ... }
  
  O en algún método:
  
  
  Código (java) [Seleccionar] Expandir
  @Interceptors(MisInterceptores.class)
public void doSomething() { ... }
  
  Si queremos que un método no sea interceptado, lo anotamos con @ExcludeClassInterceptors.
  
  Veamos un ejemplo:
  
  
  
  
  Vamos con nuestro interceptor:
  
  
  Código (java) [Seleccionar] Expandir
  public class LoginInterceptor {
    private @Inject Logger logger;

    @AroundConstruct
    private Object init(InvocationContext ic) throws Exception {
        logger.log(Level.INFO, "--- ConstructInterceptor ---");
        logger.log(Level.INFO, "Entrando al constructor");
        try {
            return ic.proceed();
        } finally {
            logger.log(Level.INFO, "Saliendo del constructor");
        }
    }
    @AroundInvoke
    private Object interceptMethod(InvocationContext ic) throws Exception {
        logger.entering(ic.getTarget().toString(), ic.getMethod().getName());
        try {
            logger.log(Level.INFO, "método interceptado");
            return ic.proceed();
        } finally {
            logger.exiting(ic.getTarget().toString(), ic.getMethod().getName());
        }
    }   
}
  
  Y nuestra clase que se verá afectada por nuestro inteceptor:
  
  
  Código (java) [Seleccionar] Expandir
  @Interceptors(LoginInterceptor.class)
public class LoginService {
    private @Inject Logger logger;
   
    public void login() {
        logger.log(Level.INFO, "Haciendo login");
    }
}
  
  Cuando se instancie ésta clase y cuando llamemos al método login(), se ejecutarán los interceptores que hemos definido en LoginInterceptor, que son uno a nivel de método y otro a nivel de constructor.
  
  

  También se pueden proporcionar más de un interceptor, deben separarse por comas:

  
  
  Código (java) [Seleccionar] Expandir
  @Interceptors(LoginInterceptor.class, AccountcheckerInterceptor.class)
public class LoginService { ... }
  
  Los interceptores serán ejecutados en el orden que son escritos.
  
  
  Vinculación de interceptores (@InterceptorBinding)
  
  Una manera más práctica y que es la más aconsejada por su bajo acoplamiento, es Interceptor Binding. Es muy fácil de hacer, solo basta crear un Interceptor Binding que es muy parecido a un calificador:
  
  
  Código (java) [Seleccionar] Expandir
  @InterceptorBinding
@Retention(RUNTIME)
@Target({METHOD, TYPE})
public @interface Loggable { }
  
  El interceptor cambia muy poco, solo debemos anotar con @Interceptor y el interceptor binding que hemos creado, en nuestro caso, @Loggable:
  
  
  Código (java) [Seleccionar] Expandir
  @Interceptor
@Loggable
public class LoginInterceptorBinding { ... }
  
  Ahora, en nuestra clase objetivo (donde se interceptarán los métodos), solo debemos anotar la clase o los métodos/constructor que queremos interceptar. Por ejemplo:
  
  
  Código (java) [Seleccionar] Expandir
  public class LoginServiceBinding {
    @Loggable
    public void Login() {
        ...
    }
}
  
  Como se puede observar, es mucho más práctico de esta forma y además, más agradable a la vista. Para poder utilizar ésta manera, debemos de agregar nuestro interceptor binding en el descriptor de beans (beans.xml):
  
  
  Código (xml) [Seleccionar] Expandir
  <beans xmlns="http://xmlns.jcp.org/xml/ns/javaee"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
       http://xmlns.jcp.org/xml/ns/javaee/beans_1_1.xsd"
       bean-discovery-mode="all">
    <interceptors>
        <class>com.acme.interceptors.binding.LoginInterceptorBinding</class>
    </interceptors>
</beans>
  
  Prioridad de interceptores
  
  Los interceptores sigue el orden en el que los hemos escrito en la clase interceptada, pero podemos crear nuestro propio orden. Por ejemplo, tenemos dos interceptores con prioridad diferente:
  
  
  Código (java) [Seleccionar] Expandir
  @Interceptor
@CdDisponibility
@Priority(200)
public class CdDisponibilityInterceptor {
    @Inject
    private Logger logger;
   
    @AroundInvoke
    public Object checkCdDisponibility(InvocationContext ic) throws Exception {
        try {
            logger.log(Level.INFO, "Ejecuando método interceptor checkCdDisponibility");
            return ic.proceed();
        } finally {
            logger.log(Level.INFO, "Terminando ejecución método interceptor checkCdDisponibility");
        }
    }
}
  
  
  Código (java) [Seleccionar] Expandir
  @Interceptor
@DvdDisponibility
@Priority(300)
public class DvdDisponibilityInterceptor {
    @Inject
    private Logger logger;
   
    @AroundInvoke
    public Object checkDvdDisponibility(InvocationContext ic) throws Exception {
        try {
            logger.log(Level.INFO, "Ejecutando método interceptor checkDvdDisponibility");
            return ic.proceed();
        } finally {
            logger.log(Level.INFO, "Terminando ejecución del método interceptor checkDvdDisponibility");
        }
    }
}
  
  Ahora, nuestra clase interceptada:
  
  
  Código (java) [Seleccionar] Expandir
  @CdDisponibility @DvdDisponibility
public class SellService {
    public void checkDisponibility() {
        ...
    }
}
  
  Si ejecutamos, veremos la siguiente salida:
  
  
  Código [Seleccionar] Expandir
  Información:   Ejecuando método interceptor checkCdDisponibility
Información:   Ejecutando método interceptor checkDvdDisponibility
Información:   Terminando ejecución del método interceptor checkDvdDisponibility
Información:   Terminando ejecución método interceptor checkCdDisponibility
  
  Como vemos, el primer interceptor (menor prioridad) se ejecuta primero y el segundo (mayor prioridad), se ejecuta después de éste, pero el segundo termina primero. Luego que termina el interceptor de mayor prioridad, el flujo vuelve hacia el de menor prioridad.
  
  
  Decoradores (@Decorator)
  
  Decorador es un patrón de diseño muy común, originalmente acuñado por Gang of Four (la banda de los cuatro). La idea detrás de este patrón es tomar una clase y envolverla con otra (se dice que esta la decora). De esta manera, cuando tu llamas a una clase decorada, debes pasar a través del decorador antes que alcances la clase objetivo. Los decoradores son usados para añadir lógica a un método.
  
  Tomemos como ejemplo un registro para una tienda de CDs online. Hay la membresía básica, que los permite acceder gratis a 15 CDs. Luego, cuando hay ofertas, viene el decorador que lo que hace es incrementar la cantidad de CDs a 40 (+25 del decorador).
  
  interface Membership
  
  
  Código (java) [Seleccionar] Expandir
  public interface Membership {
    public int freeCDs();
}
  
  Implementación BasicMembership
  
  
  Código (java) [Seleccionar] Expandir
  @Basic
public class BasicMembership implements Membership {
    @Inject
    private Logger logger;
   
    @Override
    public int freeCDs() {
        logger.log(Level.INFO, "[+] Clase BasicMembership");
        logger.log(Level.INFO, "Gratis 15 CDs");
        return 15;
    }
}
  
  @Basic es un calificador, que como ya sabemos sigue ésta anatomía:
  
  
  Código (java) [Seleccionar] Expandir
  @Qualifier
@Retention(RUNTIME)
@Target({FIELD, TYPE, METHOD, PARAMETER})
public @interface Basic { }
  
  Ahora, veamos nuestro decorador:
  
  Decorador MembershipGiftDecorator
  
  
  Código (java) [Seleccionar] Expandir
  @Decorator
public class MembershipGiftDecorator implements Membership {
    @Inject @Delegate @Basic
    private Membership membership;
    @Inject
    private Logger logger;
   
    public int orderGift() {
        logger.log(Level.INFO, "[+] Clase decoradora para Membership");
        logger.log(Level.INFO, "Regalo momentáneo de 25 CDs");
        return membership.freeCDs() + 25;
    }
    @Override
    public int freeCDs() {
        return orderGift();
    }
}
  
  Lo primero que vemos, es que hemos anotado el decorador con @Decorator. Esta anotación le dirá al contenedor que es decorador. Un decorador debe implementar a la interface de la implementación que quiere decorar, es por eso que el decorador implementa también a Membership. Dentro del decorador, vemos que inyectamos la implementación BasicMempership (@Basic) y la anotamos con @Delegate para indicar que ese bean será decorado. A continuación, sobreescribimos el método de la interface y añadimos la lógica de negocio que deseamos. En nuestro caso, agregar 25 CDs gratis.
  
  Por último hacemos uso del decorador:
  
  
  Código (java) [Seleccionar] Expandir
  @Named
public class MembershipBean {
    @Inject @Basic
    private Membership gift;
   
    public void orderGift() {
        gift.freeCDs();
    }
}
  
  Vemos que NO inyectamos al decorador, si no al bean normal (@Basic). El contenedor se encarga de añadir la lógica del decorador al método del bean. Si ejecutamos, vemos ésta salida:
  
  
  Código [Seleccionar] Expandir
  Información:   [+] Clase decoradora para Membership
Información:   Regalo momentáneo de 25 CDs
Información:   [+] Clase BasicMembership
Información:   Gratis 15 CDs
  
  El orden es porque yo he ejecutado primero la lógica del decorador y al último del bean. Si hubiera sido al revés, el resultado hubiera sido invertido.
  Los decoradores no están activados por defecto en CDI, así que debemos listarlos en el descriptor beans.xml:
  
  
  Código (xml) [Seleccionar] Expandir
  <decorators>
        <class>com.acme.decorator.MembershipGiftDecorator</class>
</decorators>
  
  Eventos
  
  Los eventos permiten a los beans interactuar con sus dependencias en tiempo de no-compilación. Cuando un bean define un evento, otro bean puede disparar el evento e incluso otro bean puede manejar el evento. Los beans pueden estar en paquetes y capas distintos dentro de la aplicación. El esquema que siguen éstos eventos es el observer/observable, de Gand of four.
  
  Los productores de los eventos disparan los eventos usando la interface Event (javax.enterprise.event.Event). Un productor eleva eventos llamando el método fire(), pasando el objeto asociado al evento.
  
  Veamos un ejemplo. En nuestra tienda online de CDs, cada vez que se quiera agregar un ítem al carro, deseamos disparar un evento CDI que envíe el ítem que se desee agregar al método observador addItem y reciba el ítem elegido por el usuario para que se agrege al carro.
  
  Vamos con nuestro bean CDShopCart:
  
  
  Código (java) [Seleccionar] Expandir
  @Named("cdShopCart")
@RequestScoped
public class CDShopCart {
    @Inject
    private Event<CD> cdAddedEvent;
   
    public void addItem2cart() {
        List<String> songs = new ArrayList<>();
        Collections.addAll(songs,
                "The day that never comes",
                "Enter Sandman",
                "The fourth horseman",
                "Whiskey in the jar");
        CD cd = new CD("Metallica", songs);
        cdAddedEvent.fire(cd);
    }
}
  
  Este bean tendrá un alcande de petición (@RequestScoped), es decir que su ciclo de vida será igual al de una petición HTTP. Esto es así porque solo vamos a utilizar este bean para agregar un ítem (CD) al carro. Vemos que hemos definido una propiedad tipo Event que acepta datos tipo CD. Cuando se ejecute el método addItem2cart, se ejecutará el evento CDI y se enviará un bean CD para que sea procesado por el método observador, que lo define la siguiente clase:
  
  
  Código (java) [Seleccionar] Expandir
  @SessionScoped
public class Cart implements Serializable {
    @Inject
    private transient Logger logger;
    private List<CD> items;
   
    @PostConstruct
    public void init() {
        items = new ArrayList<>();
    }
   
    public void addItem(@Observes CD cd) {
        logger.log(Level.INFO, "Nuevo CD añadido al carro");
        logger.log(Level.INFO, "Autor: {0}", cd.getAuthor());
        logger.log(Level.INFO, "Canciones:");
        for(String song : cd.getSongs()) {
            logger.log(Level.INFO, song);
        }
    }
}
  
  El método addItem() es el método observador. Este método escucha el evento y cuando se lanza lo captura y recibe el objeto asociado con el evento lanzado, en este caso CD. Es conveniente que la entidad CD sea pasivada (implemente Serializable). Además, vemos que el carro de compras está marcado como @SessionScoped ya que el carro de compras estará ligado siempre a la sesión de un usuario.
  
  Para disparar el evento, podemos usar JSF, por ejemplo:
  
  
  Código (html5) [Seleccionar] Expandir
  <h:form>
            <h:commandButton value="Agregar CD al carro" actionListener="#{cdShopCart.addItem2cart()}">
                <f:ajax execute="@form"/>
            </h:commandButton>
        </h:form>
  
  Cuando se haga click en el botón, se ejecutará el método y se lanzará el evento. Si hacemos click, veremos lo siguiente en el log:
  
  
  Código [Seleccionar] Expandir
  Información:   Nuevo CD añadido al carro
Información:   Autor: Metallica
Información:   Canciones:
Información:   The day that never comes
Información:   Enter Sandman
Información:   The fourth horseman
Información:   Whiskey in the jar
  
  Ahora, para hacer más interesante nuestro ejemplo, podemos crear calificadores llamados @Added y @Removed para identificar a cada evento: Agregar y Eliminar. Para esto, debemos hacer unos pequeños cambios:
  
  Debemos cambiar el alcance de CDShopCart de @RequestScoped a @SessionScoped:
  
  
  Código (java) [Seleccionar] Expandir
  @Named("cdShopCart")
@SessionScoped
public class CDShopCart implements Serializable {
    @Inject @Added
    private Event<CD> cdAddedEvent;
    @Inject @Removed
    private Event<CD> cdRemovedEvent;
    @Inject
    private CD cd;
   
    public void addItem2cart() {
        List<String> songs = new ArrayList<>();
        Collections.addAll(songs,
                "The day that never comes",
                "Enter Sandman",
                "The fourth horseman",
                "Whiskey in the jar");
        cd.setAuthor("Metallica");
        cd.setSongs(songs);
        cdAddedEvent.fire(cd);
    }
    public void removeItemFromCart() {
        cdRemovedEvent.fire(cd);
    }
}
  
  Los métodos observadores del carro, se verán así:
  
  
  Código (java) [Seleccionar] Expandir
  public void addItem(@Observes @Added CD cd) {
        logger.log(Level.INFO, "Nuevo CD añadido al carro");
        logger.log(Level.INFO, "Autor: {0}", cd.getAuthor());
        logger.log(Level.INFO, "Canciones:");
        for(String song : cd.getSongs()) {
            logger.log(Level.INFO, song);
        }
    }
    public void removeItem(@Observes @Removed CD cd) {
        logger.log(Level.INFO, "CD Removido");
        logger.log(Level.INFO, "Autor: {0}", cd.getAuthor());
    }
  
  Prestar atención al calificador después de @Observes. Esto identifica al evento disparado, @Added representa un nuevo CD agreado y @Removed eliminará un CD del carro.
  
  Nuestra web, se verá así:
  
  
  Código (html5) [Seleccionar] Expandir
  <h:form>
            <h:commandButton value="Agregar CD al carro" action="#{cdShopCart.addItem2cart()}">
                <f:ajax execute="@form"/>
            </h:commandButton>
            <h:commandButton value="Eliminar CD del carro" action="#{cdShopCart.removeItemFromCart()}">
                <f:ajax execute="@form"/>
            </h:commandButton>
        </h:form>
  
  
  
  
  
  
  Descarga en PDF
  
  https://mega.nz/#!bpBmxSAA!ize0-Dy5Urqh20AP-jH_18mwIEcsjAjQnNNGvRkwiFQ
  
  
  
  Eso es todo lo que quería compatirles acerca de CDI. Es un tema muy importante y que pocos entienden y comprenden cómo funciona. Espero que el presente documento es ayuda a entender un poquito mejor cómo funciona CDI y sus nuevas características.
  
  Nos vemos en otra oportunidad, hasta la próxima.

[Servlet]

Subir archivos en Java es realmente muy sencillo. Ya Java nos provee interfaces como Part para facilitarnos el trabajo. Veamos un ejemplo:

Vamos con nuestro sencillo formulario:

Código (html5) [Seleccionar] Expandir


<h1>Subir archivos</h1>
    <form method="post" action="upload" enctype="multipart/form-data">
    <fieldset>
    <legend>Formulario de subida</legend>
    <input type="file" name="files" id="files" multiple/>
        <button type="submit">Subir</button>
    </fieldset>
</form>

Como podemos observar no hay nada del otro mundo. Simplemente un input tipo file e indicamos que se podrán elegir múltiples archivos. Por últmo, el botón submit.

Servlet

Nuestro servlet será como cualquier otro, pero añadiremos la anotación @MultipartConfig, que básicamente, identificará el servlet como un servlet multipart/form-data.

Código (java) [Seleccionar] Expandir

@WebServlet(name = "UploadServlet", urlPatterns = {"/upload"})
@MultipartConfig(location="D:/uploads")
public class UploadServlet extends HttpServlet {
    private static final long serialVersionUID = 1L;
   
    protected void processRequest(HttpServletRequest request, HttpServletResponse response)
            throws ServletException, IOException {
        response.setContentType("text/html;charset=UTF-8");
        Collection<Part> parts = request.getParts();
        for(Part part : parts) {
        part.write(getFileName(part));
        }
    }

    @Override
    protected void doGet(HttpServletRequest request, HttpServletResponse response)
            throws ServletException, IOException {
        processRequest(request, response);
    }

    @Override
    protected void doPost(HttpServletRequest request, HttpServletResponse response)
            throws ServletException, IOException {
        processRequest(request, response);
    }

    public String getFileName(Part part) {
        String contentHeader = part.getHeader("content-disposition");
        String[] subHeaders = contentHeader.split(";");
        for(String current : subHeaders) {
            if(current.trim().startsWith("filename")) {
            int pos = current.indexOf('=');
                String fileName = current.substring(pos+1);
                return fileName.replace("\"", "");
            }
        }
        return null;
    }
}

El atributo location sirve para especificar la ruta donde se guardarán los archivos recibidos. Ésto porsupuesto puede hacerse desde código también. En mi caso, he decidido guardarlas en D:/uploads.

Primero, recibimos todos los part mediante el método getParts() del objeto HttpServletRequest. Cada part viene a ser una parte que representa a cada elemento enviado. El payload de la petición se ve así:

Código (text) [Seleccionar] Expandir

------WebKitFormBoundaryKZUc66kZeBth3nDc
Content-Disposition: form-data; name="files"; filename="jsf-scopes.png"
Content-Type: image/png


------WebKitFormBoundaryKZUc66kZeBth3nDc
Content-Disposition: form-data; name="files"; filename="navbar.png"
Content-Type: image/png

Donde Content-Disposition y Content-Type son las cabeceras de las peticiones por cada part (elemento) enviado.  Es importante saber la anatomía de éstas peticiones, porque luego las usaremos para obtener ciertos datos,  como el nombre de los archivos.

Luego, recorremos los parts y por cada uno de ellos, obtenemos su nombre llamando al método getFileName el cual recibe un part y devuelve el nombre del archivo/elemento al que corresponde:

Código (java) [Seleccionar] Expandir

public String getFileName(Part part) {
        String contentHeader = part.getHeader("content-disposition");
        String[] subHeaders = contentHeader.split(";");
        for(String current : subHeaders) {
            if(current.trim().startsWith("filename")) {
            int pos = current.indexOf('=');
                String fileName = current.substring(pos+1);
                return fileName.replace("\"", "");
            }
        }
        return null;
    }

Primero obtenemos la cabecera content-disposition la cual como vimos, almacena los datos del elemento enviado. Ahora, obtenemos los datos de esa cabecera y les llamaremos subHeaders. Los obtenemos diviendo el contenido de la cabecera por puntos y comas ( porque así está formada la petición.

En éste punto ya tenemos los siguientes datos:

• form-data
  
• name
  
• filename
  
  El que nos interesa es filename ya que éste almacena el nombre del archivo enviado. Comprobamos si la subHeader actual comienza con 'filename', si es así,  obtenemos la posición del caracter '=' para obtener todo lo que hay hacia la derecha, que es lo que nos interesa: el nombre del archivo. Por último, reemplazamos las comillas por nada (eliminar) y eliminamos los espacios en blanco al inicio/final del nombre del archivo. El resultado, el nombre del archivo solamente.
  
  Una vez que obtenemos el nombre del archivo asociado a cada part, los escribimos en el directorio especificado por el atributo location, que será D:/uploads:
  
  
  Código (java) [Seleccionar] Expandir
  
part.write(getFileName(part));
  
  Por último, verificamos si se han subido  los archivos:
  
  
  
  
  
  Eso es todo. ¿Quién dijo que Java es difícil?

[form-head]

Con el avance de las tecnologías de la web, se pueden hacer cada vez cosas mas bonitas, cosas que sin duda pueden dar una buena UX al usuario de nuestra web o aplicación web.

En el presente texto, haremos un login con algunas animaciones y un preloader que seguramente habrás visto en algunas webs cuando te logueas y aparece algo que demuestra que la web está cargando (animaciones por lo general).

(Click en la imagen para ir al demo)

Usuario: john.doe@gmail.com
Contraseña: abc123

1. INDEX

• Necesitaremos importar fontawesome y nornalize.
  
  La estructura HTML para nuestro login es sencilla:
  
  
  Código (html5) [Seleccionar] Expandir
  
<!DOCTYPE html>
<html lang="es">
<head>
<meta charset="UTF-8">
<link rel="stylesheet" href="css/vendor/normalize.css"/>
<link rel="stylesheet" href="//maxcdn.bootstrapcdn.com/font-awesome/4.3.0/css/font-awesome.min.css"/>
<link rel="stylesheet" href="css/main.css"/>
<title>Login</title>
</head>
<body>
<section class="main">
<form id="loginFrm" class="form">
<figure class="tooltip"></figure>
<section class="form-head">
<span>Login</span>
<figure class="logo"></figure>
</section>
<section class="form-body">
<div class="group">
<label for="user">Email:</label>
<input type="text" id="user" class="txt">
</div>
<div class="group">
<label for="pass">Password:</label>
<input type="password" id="pass" class="txt">
</div>
<div class="group flex-end">
<button type="submit" id="login" class="btn btn-radical">login</button>
</div>
</section>
</form>
</section>
<script>
'use strict';
window.addEventListener('load', function() {
let main = document.querySelector('.main');
main.classList.add('visible');
});
</script>
<script src="js/auth.js"></script>
</body>
</html>
  
  La estructura es muy simple. Consta de un formulario con dos partes:
  
  
  
  
  • form-head: Aquí tendremos el título del form y el pin (el círculo con el ícono de un usuario).
  • form-body: Aquí tendremos todos los grupos (label/inputs) y botones.
  
  Vemos que hay un elemento con la clase 'tooltip'. Bien, éste elemento es como su nombre lo dice, un tooltip en cual nos servirá para mostrar los errores de autenticación.
  
  Ahora veamos el CSS. Lo primero que haremos será aplicar la propiedad box-sizinz: border-box a HTML y hacer que todos los elementos hereden de él esa propiedad.
  
  
  Código (css) [Seleccionar] Expandir
  
html {
box-sizing: border-box;
}
*, *:before, *:after {
box-sizing: inherit;
}
  
  Luego, aplicamos estilos al container general, es decir, main:
  
  
  Código (css) [Seleccionar] Expandir
  
.main {
align-items: center;
background: rgba(136,211,124,1);
background: linear-gradient(to bottom, rgba(136,211,124,1) 0%,
rgba(136,211,124,1) 50%,
rgba(190,144,212,1) 51%,
rgba(190,144,212,1) 71%,
rgba(190,144,212,1) 100%);
background-repeat: repeat;
display: flex;
height: 100vh;
justify-content: center;
opacity: 0;
transition: all .2s linear;
visibility: hidden;
}
.main.visible {
opacity: 1;
visibility: visible;
}
  
  Aplicamos display: flex, align-items: center y justify-content: center para centrar el formulario, un centrado perfecto. Para ésto, .main debe de tener un alto, el cual se lo especificamos en 100vh (100 view height).
  
  También, le damos una opacidad de 0 y una visibilidad oculta (hidden), además un transition: all .2s ease-in para que al cambiar opacity a 1 y visibility a visible, el efecto sea suave y bonito. Aquí es donde toma importancia .visible, que solamente cambia la opacidad y la visibilidad de .main.
  
  Ahora vayamos con el formulario:
  
  
  Código (css) [Seleccionar] Expandir
  
.form {
background-color: #f7f7f7;
border: none;
border-radius: 2px;
box-shadow: 0 2px 5px rgba(0,0,0,.25),
0 -1px 5px rgba(0,0,0,.1);
position: relative;
width: 350px;
}
  
  Nada relevante. Solo tiene un color blanco humo, sin bordes, un redondeado de 2px, una sombra, un ancho y lo importante, una posición relative. Esta propiedad nos permitirá situar el pin y el tooltip con relación al formulario.
  
  
  Código (css) [Seleccionar] Expandir
  
.form-head {
align-items: center;
border-radius: 2px 2px 0 0;
border-bottom: 2px solid #9B59B6;
display: flex;
height: 45px;
}
.form-head > span {
color: #555;
font-family: 'segoe ui';
font-size: 17pt;
font-weight: lighter;
margin-left: 12px;
}
  
  La cabecera del formulario no tiene nada que explicar. Vayamos con el pin:
  
  
  Código (css) [Seleccionar] Expandir
  
.form-head .logo {
background-position: center;
background-repeat: no-repeat;
background-image: url('http://urbita.com/img/default/default_user_256.png');
background-size: cover;
border-radius: 100%;
box-shadow: 0px 2px 5px rgba(0,0,0,.25);
height: 85px;
left: calc(50% - 38.5px);
margin: 0px;
position: absolute;
top: calc(0% - 38.5px);
width: 85px;
}
  
  El pin tiene un ancho y alto de 85px, además un border-radius de 100%, lo que le dará la forma de un círculo. Tiene una pequeña sombra con un offset Y de 2px, lo que hará que la sombra se despligue hacia abajo. Las propiedades de background permiten que la imagen se centre y que cubra el tamaño del círculo.
  
  La parte más importante es la propiedad position: absolute. Esta instrucción nos permite posicionar el pin de acuerdo al padre. Ahora, podemos centrarlo horizontalmente con solo left: calc(50% - 38.5px) y verticalmente con top: calc(0% - 38.5px) (por cuestión de entendimiento, si preguntas porqué no hice -38px xD). Ahora tenemos en pin centrado en la cabecera. ¿Fácil no?
  
  Ahora, hagamos algo de magia. Hagamos al pin animado, para ésto, usaremos keyframes:
  
  
  Código (css) [Seleccionar] Expandir
  
@keyframes spin {
from { transform: rotate(0deg); }
to { transform: rotate(1800deg); }
}
  
  La animación se llamará spin, y el elemento que la use empezará con una rotación de 0 grados y terminará con una rotación de 1800 grados (5 vueltas completas). Ahora, el pin la usará cuando tenga la clase 'auth', que informa que se ha hecho una autenticación en el formulario:
  
  
  Código (css) [Seleccionar] Expandir
  
.form-head .logo.auth {
animation-name: spin;
animation-duration: 3000ms;
animation-iteration-count: 1;
animation-timing-function: linear;
animation-play-state: running;
animation-fill-mode: forwards;
animation-delay: 0s;
}
  
  La duración será de 3 segundos. Solo iterará una vez, será a una velocidad plana (linear) y sin tardanza antes de empezar la animación.
  
  Ahora vayamos con el cuerpo del formulario:
  
  
  Código (css) [Seleccionar] Expandir
  
.form-body {
padding: 40px 25px 10px 25px;
}
.group {
align-items: center;
display: flex;
margin-bottom: 10px;
}
.group > label {
color: #777;
display: block;
flex-grow: 1;
font-family: 'segoe ui';
}
  
  El cuerpo de formulario tendrá un padding de 40px hacia arriba, 25px hacia los lados y 10px hacia abajo (lo último para contrarrestrar el margin-bottom de los grupos, que contiene los label y los input. Los labels serán en forma de bloque y con un flex-grow: 1 que hará que el label tenga un tamaño definido.
  
  Pondremos éstas 2 clases como apoyo, la primera para alinear los elementos hacia el final del bloque, y el otro para un centrado absoluto:
  
  
  Código (css) [Seleccionar] Expandir
  
.flex-end {
justify-content: flex-end;
}
.flex-abs-center {
align-items: center;
justify-content: center;
}
  
  Ahora vayamos con los textboxes:
  
  
  Código (css) [Seleccionar] Expandir
  
.txt {
border: 1px solid #ddd;
border-radius: 2px;
color: #777;
font-family: 'segoe ui';
font-size: .9rem;
outline: none;
padding: .35rem .5rem;
transition: all .2s ease;
}
.txt.invalid {
border-color: rgba(231,76,60,.7);
}
.txt:hover {
border-color: #ccc;
}
.txt:focus {
border-color: #bbb;
}

  
  Nada del otro mundo. La clase invalid solo pintará el borde del textbox de rojo. Ahora los botones:
  
  
  Código (css) [Seleccionar] Expandir
  
.btn {
border: none;
border-radius: 2px;
box-shadow: 0 2px 5px rgba(0,0,0,.2);
font-family: 'segoe ui';
font-size: .9rem;
outline: none;
padding: .45rem 1.25rem;
text-transform: uppercase;
transition: all .3s ease;
}
.btn-radical {
background-color: #F62459;
color: rgba(255,255,255,.9);
margin-top: 15px;
}
.btn-radical:hover {
background-color: #DC1F4E;
}
  
  Tampoco nada que destacar. Un redondeado de 2px, fuente segoe ui, una ligera sombra y un padding. btn-radical solo le da color (radical) y un margin-top de 15px.
  
  Por último, finalizaremos con el tooltip:
  
  
  Código (css) [Seleccionar] Expandir
  
.form .tooltip {
background-color: rgba(0,0,0,.5);
border-radius: 5px;
box-shadow: 0px 2px 5px rgba(0,0,0,.25);
color: rgba(255,255,255,.8);
font-family: 'segoe ui';
font-size: .9rem;
height: 100px;
left: calc(100% - 35px);
margin: 0;
padding: .7rem .6rem;
opacity: 0;
position: absolute;
text-align: center;
top: -140%;
transition: all .4s ease-in;
visibility: hidden;
width: 200px;
}
  
  El tooltip tiene un alto de 200px y un ancho de 100px. Tiene una posición absoluta, lo cual nos hace ubicarlo fácilmente de acuerdo a su padre (formulario). Le damos un left para que quede tirado más a la derecha y un top negativo muy grande para desplazarlo muy arriba, además una opacidad de 1.  Le damos un top muy alto porque en la transición, lo bajaremos y así da la impresión que viene aparece de la nada (por la opacidad también).
  
  Para hacer el efecto de la flecha, jugaremos un poco con las pseudoclases :before:
  
  
  Código (css) [Seleccionar] Expandir
  
.form .tooltip:before {
border-color: rgba(0,0,0,.5) transparent;
border-style: solid;
border-width: 10px 10px 0px 10px;
content: "";
left: 10px;
position: absolute;
bottom: -10px;
}[/coder]

Por último, para hacerlo visible, aplicaremos una clase:

[code=css]
.form .tooltip.visible {
opacity: 1;
top: -50%;
visibility: visible;
}
  
  La clase visible, cambia la opacidad del tooltip, visiblidad y le da un top de -50%. Ésto lo que genera, es un efecto que el tooltip viene de arriba y en el camino se hace visible.
  
  Código JS
  
  
  Código (javascript) [Seleccionar] Expandir
  
'use strict';
document.addEventListener('DOMContentLoaded', function() {
let loginFrm = document.querySelector('#loginFrm');

loginFrm.addEventListener('submit', function(e) {
e.preventDefault();

const ANIMATION_TIMEOUT = 3000; // duration of logo animation
let logo = document.querySelector('.logo');
let user = document.querySelector('#user').value.toLowerCase();
let pass = document.querySelector('#pass').value;

// if logo already is animated, the info is already processing
if(logo.classList.contains('auth')) {
return false;
}

logo.classList.add('auth'); // start animation

// check credentials
if(user == 'john.doe@gmail.com' && pass == 'abc123') {
window.setTimeout(function() {
sessionStorage.setItem('full_access', false);
window.location.href = 'views/home.html';
}, ANIMATION_TIMEOUT);
} else {
window.setTimeout(function() {
logo.classList.remove('auth'); // remove animation of logo
showTooltip();
}, ANIMATION_TIMEOUT);
}
});

// show and hide tooltip
function showTooltip() {
let tooltip = loginFrm.querySelector('.tooltip');
tooltip.textContent = 'El email o contraseña ingresados no son correctos. Verifique e inténtelo nuevamente.';
tooltip.classList.add('visible');
// after 4 seconds, the tooltip disappear
window.setTimeout(function() {
tooltip.classList.remove('visible');
}, 4000);
}
}); // end script
  
  El script es muy simple. Escuchamos por evento submit del formulario y obtenemos lo que se ha ingresado en las cajas de texto; también añadimos una constante llamada ANIMATION_TIMEOUT que especifica el tiempo que durará la animación del pin.
  
  Añadimos la clase 'auth' al pin para empezar la animación. Comprueba las credenciales y si coinciden crear una sessión para el usuario (HTML5 WebStorage) y redirige hacia home, todo ésto con un delay del mismo tiempo que dura la animación, esto es, que una vez que acaba la animación, se redigirá hacia home.
  
  Si las credenciales no coindicen, quitamos la clase 'auth' del pin para poder volver a iniciar la animación las veces que se requiera. Además, mostramos el tooltip informando de los errores de credenciales. El mismo tooltip desaparecerá al cabo de 4 segundos.
  
  El script embebido lo único que hace es hacer visible el index para darle el efecto de 'aparición':
  
  
  Código (javascript) [Seleccionar] Expandir
  
'use strict';
window.addEventListener('load', function() {
let main = document.querySelector('.main');
main.classList.add('visible');
});
  
  
  
  2. HOME
  
  
  HTML
  
  
• Normalize.css requerido
  
• Prefixfree requerido
  
  
  Código (html5) [Seleccionar] Expandir
  
<!DOCTYPE html>
<html lang="es">
<head>
<meta charset="UTF-8">
<link rel="stylesheet" href="../css/vendor/normalize.css"/>
<link rel="stylesheet" href="//maxcdn.bootstrapcdn.com/font-awesome/4.3.0/css/font-awesome.min.css"/>
<link rel="stylesheet" href="../css/home.css"/>
<script src="js/vendor/prefixfree.min.js"></script>
<title>Home page</title>
</head>
<body>
<section class="preload"><i class="fa fa-4x fa-circle-o-notch fa-spin"></i></section>
<section class="main">
<header>
<nav class="navbar">
<!-- brand -->
<a href="#" class="brand">Oh yeah!<i class="fa fa-2x fa-hand-o-right"></i></a>
<!-- menu -->
<ul class="menu">
<li><a href="#">Messages<i class="fa fa-envelope"></i></a></li>
<li>
<a href="#">John doe<i class="fa fa-caret-down"></i></a>
<ul>
<li><a href="#" id="profile-img">
<img src="http://i.imgur.com/IxWfQy2.jpg"/></a>
</li>
<li><a href="#">Profile<i class="fa fa-user"></i></a></li>
<li><a href="#">Settings<i class="fa fa-cog"></i></a></li>
<li><a href="#" id="logout">Logout<i class="fa fa-sign-out"></i></a></li>
</ul>
</li>
</ul>
</nav>
</header>
</section>
<script src="js/homeui.js"></script>
</body>
</html>
  
  El marcado es simple. Consta de un header y un nav, con una lista incluída con dos elementos: Messages y un dropdown. El dropdown contiene una lista que son las opciones del usuario logueado.
  
  CSS
  
  Primero hacemos todos los elementos border-box:
  
  
  Código (css) [Seleccionar] Expandir
  
html { box-sizing: border-box; }
*, *:before, *:after { box-sizing: inherit; }
  
  Preload:
  
  El preload es un simple etiqueta section con un elemento i dentro, el cual será la animación. Veamos que elementos tiene:
  
  
  Código (css) [Seleccionar] Expandir
  
.preload {
align-items: center;
background-color: #F22613;
display: flex;
height: 100vh;
justify-content: center;
left: 0;
opacity: 0;
position: absolute;
top: 0;
transition: all .5s ease;
visibility: hidden;
width: 100%;
z-index: 1;
}
.preload.visible {
opacity: 1;
visibility: visible;
}
.preload i {
color: rgba(255,255,255,.9);
}
  
  Como vemos, preload ocupa el 100%(100vh) de alto y ancho, además es de posición absoluta y se posiciona en el vértice izquierdo, lo que junto con sus medidas hace que cubra toda la pantalla. Tiene una opcidad de 0 y una visibilidad oculta (hidden) por defecto, además se comporta como flexbox y tiene un centrado absoluto (flex-align: center y justify-content: center).
  
  El color del ícono animado es de color blanco con una opacidad de .9 (hace que se note apenas el fondo). La clase que activa la animación, se llama visible y lo único que hace es cambiar la opacidad a 1 y la visibilidad a visible.
  
  El elemento i es animado con la ayuda de font awesome, pero se puede hacer manualmente, quizás lo veamos en otro tutorial.
  
  Main
  
  El main es donde están todos nuestros elementos. Es el container general. Tiene las siguientes propiedades:
  
  
  Código (css) [Seleccionar] Expandir
  
.main {
opacity: 0;
transition: all .6s ease;
visibility: hidden;
}
.main.visible {
opacity: 1;
visibility: visible;
}
  
  Creo que en este punto ya sabemos que significa... Oculto por defecto y cuando se aplica la clase visible, se hace visible con animación. Ahora veamos el header y el nav:
  
  
  Código (css) [Seleccionar] Expandir
  
header {
background-color: #22A7F0;
color: rgba(255,255,255,.9);
display: block;
}
.navbar {
align-items: center;
color: inherit;
display: flex;
justify-content: space-between;
margin: 0px;
padding: 0 .5rem;
width: 100%;
}
  
  Ambos tienen un ancho de 100%. El header es block y nav es flex. El nav tiene la propiedad justify-content: space-between, que hace que los hijos de alineen hacia los lados dejando todo el espacio restante del padre entre ellos. ¿Cuáles son los hijos? Son el logo de la empresa y la lista.
  
  El logo de la empresa tiene la clase brand y tiene los siguientes estilos:
  
  
  Código (css) [Seleccionar] Expandir
  
.brand {
align-self: stretch;
align-items: center;
color: inherit;
display: flex;
font-family: 'segoe ui';
margin: 0px;
padding: 0 .25rem;
}
.brand > i {
margin-left: .8rem;
}
  
  De entrada, podemos ver que el brand tiene la propiedd align-self: stretch. Ésta propiedad sobreescribe el comportamiento por defecto de un hijo flex en fila (por defecto display: flex) en el eje Y. Es decir, si el padre especifica un align-items: center y el hijo especifica align-self, stretch, predomina el comportamiento del hijo. El valor stretch hace que el hijo se estire ocupando todo el alto del padre.
  
  Veamos la lista y sus elementos:
  
  
  Código (css) [Seleccionar] Expandir
  
.navbar ul {
display: block;
list-style: none;
margin: 0px;
padding: 0px;
}
.navbar > .menu {
display: block;
}
.menu > li {
display: inline-block;
transition: all .1s ease-in;
}
.menu > li:hover {
background-color: #1C99DD;
}
  
  La lista es un bloque y sus elementos son bloque en línea, lo que hace que se muestre en forma horizontal dentro de la lista. Además, tienen una transición que anima el cambio de fondo cuando se hace hover sobre ellos. Además, ellos tendrán un margen a la derecha de 55px siempre y cuando no sea el último elemento de la lista y sus hijos (elementos a) serán elementos de bloque y tendrán cierto padding:
  
  
  Código (css) [Seleccionar] Expandir
  
.menu > li > a {
display: block;
padding: 1rem .5rem;
}
.menu > li > a > i {
margin-left: 10px;
}
.menu > li:not(:last-of-type) {
margin: 0 55px 0 0;
}
  
  Veamos ahora, el dropdwon que serán las opciones del usuario.
  
  
  Código (css) [Seleccionar] Expandir
  
/* last li (profile dropdown) */
.menu > li:last-of-type {
position: relative;
}
/* dropdown */
.menu > li:last-of-type > ul {
background-color: #22A7F0;
border-radius: .1725rem;
left: -50%;
opcity: 0;
padding: .5rem 0;
position: absolute;
top: 170%;
visibility: hidden;
transition: all .14s ease-in;
}
/* arrow of menu */
.menu > li:last-of-type > ul:after {
border-color: #22A7F0 transparent;
border-style: solid;
border-width: 0 8px 8px 8px;
content: "";
position: absolute;
right: 8px;
top: -7px;
}
.menu > li:last-of-type:hover > ul {
opacity: 1;
top: 130%;
visibility: visible;
}

  
  El menú de usuario (dropdown), tendrá una posición relative, lo que permitirá aplicar a su lista interna, una posición absoluta y posicionarla debajo. La lista como ya dijimos tiene posición absoluta, una opacidad de 0, visibilidad oculta (hidden), un left de -50% lo que hará que la lista se desplace a la izquierda y un top de 170% que posiciona la lista muy abajo.
  
  Cuando se haga hover en el menú de usuario, la lista interna se hace visible (opacidad, visibility) y el top se reduce a 130%, lo que da el efecto de desplazamiento hacia arriba mientras se hace visible.
  
  Los li y a de la lista interna, ambos son block lo que hace que se muestre en forma de columna. Además, los li tienen se animan en cuanto se haga hover sobre ellos y se cambie el color.
  
  
  Código (css) [Seleccionar] Expandir
  
/* dropdown list items*/
.menu > li:last-of-type > ul > li, .menu > li:last-of-type > ul a {
display: block;
font-size: .9rem;
transition: transform .1s ease-in;
}
/* dropdown options */
.menu > li:last-of-type > ul a {
padding: .5rem .9rem;
width: 8rem;
}
/* a elements of dropdown options */
.menu > li:last-of-type > ul li:hover {
background-color: #1998DC;
}
/* margin left to dropdown icon */
.menu > li:last-of-type > a > i {
margin-left: .8rem;
}
/* dropdown options icons */
.menu li:last-of-type > ul a > i {
float: right;
margin-top: .3125rem;
}
  
  Por último, la sección donde irá el avatar del usuario:
  
  
  Código (css) [Seleccionar] Expandir
  
/* profile image */
#profile-img {
display: flex;
justify-content: center;
margin-bottom: 5px;
pointer-events: none;
width: 100%;
}
#profile-img > img {
background-position: center;
background-size: cover;
border-radius: 50%;
display: block;
height: 5rem;
width: 5rem;
}
  
  La sección que contiene la imagen del usuario es un bloque tipo flex que ocupa el 100% y que alinea la imagen al centro horizontal (justify-content: center). La imagen tiene un ancho y alto de 5rem (80px) y la imagen estará centrada y ocupara todos los 80px.
  
  El resultado:
  
  
  
  
  Código JS:
  
  
  Código (javascript) [Seleccionar] Expandir
  
'use strict';
window.addEventListener('load', function() {
let full_access = sessionStorage.getItem('full_access');
let preload = document.querySelector('.preload');
let main = document.querySelector('.main');
// full_access is gived when user enter for first time
if(full_access == "false") {
// show preload animation
preload.classList.add('visible');
// animation delay 3s. After that, the main content appear
window.setTimeout(function() {
preload.classList.remove('visible');
main.classList.add('visible');
},3000);
// change the flag. Now, the user has full access
sessionStorage.setItem('full_access', true);
}
// if user has full_access, just show the page
else {
main.classList.add('visible');
}
});
document.addEventListener('DOMContentLoaded', function() {
document.querySelector('#logout').addEventListener('click', function(e) {
e.preventDefault();
// remove user's session
sessionStorage.removeItem('full_access');
// redirect to login
window.location.href = '/PreloadCSS';
});
});
  
  Primero obtenemos el item 'full_access' de la sesión. Como sabemos, en el login, lo inicializamos en false cuando se ha logueado el usuario por primera vez.Seleccionamos el preload y el main y los guardamos en variables locales.
  
  Verificamos, si full_access es false (lo será la primera vez que se loguee) se le aplica la clase 'visible' al preload, que como recordamos, al aplicarle visible se muestra el preload y su animación.
  
  Creamos un delay de 3 segundos (el tiempo que tarda la animación) y cuando termine removemos la clase active del preload, haciendo que se oculte y agregamos la clase visible al main, haciendo que éste se haga visible. Al final, cambiamos el valor full_access por true.
  
  Si ya se tiene acceso total, simplemente se agrega la clase visible al main, haciendolo visible (sin mostrar el preload). Lo anterior lo aplicamos en el evento load de window.
  
  Por último, cuando el dom esté cargado, escuchamos por evento click en la opción logout del menú de usuario, removiendo la sesión y redirigiendo al login (fíjense que éste tbn tiene un efecto).
  
  
  
  
  [/code]

[Descripción:]

Descripción: Simple pizarra virtual con soporte para toda la paleta de colores, grosor el pincel y borrador.

Características:

• Diversidad de colores.
  
• Grosor del pincel entre 1 y 30.
  
• Borrador.
  
• Limpiador de lienzo (full clean).
  
• Responsivo.
  
  
  
  
  
  
  
  
  
  
  
  C{0}digo fuente
  
  
  El source lo pueden encontrar en mi github: HTML5 Blackboard
  
  Espero que le sirva a alguien. Nos vemos.
  
  
  
  By Gus.

¿Alguien lo está viendo? Menudo discurso se ha mandado el presidente de Cuba, Raúl Castro, sobre el abuso de EEUU que ha tenido sobre Cuba.

"Nos pusieron en una lista de países patrocinadores de terrorismo, cuando nosotros éramos los que poníamos los muertos, ¿quién entonces, infringió terror?"

KO a los Yankees.

[NOTA:]

Consumir RESTful WebService CRUD en aplicación JavaFX

Éste es un demo de cómo interactuar con una BBDD remota mediante un WebService, en concreto un servicio RESTful. Las tecnologías usadas son:

• JAXB
  
• JAX-RS (implementación corre por servidor)
  
• Jersey client (para el cliente REST)
  
• JPA 2.1 (persistencia de datos)
  
• Hibernate 4.x (implementación de JPA 2.1)
  
• PostgreSQL 9.4.1 como SGBD
  
• WildFly 8.2.0
  
  
  NOTA: Si van a utilizar GlassFish 4.x, necesitan usar Hibernate 4.3.5 en lugar de 4.3.8, ya que se conocen conflictos entre ambos.
  
  En el pom.xml, reemplazar:
  
  
  Código (xml) [Seleccionar] Expandir
  
<dependency>
   <groupId>org.hibernate</groupId>
   <artifactId>hibernate-core</artifactId>
   <version>4.3.5.Final</version>
</dependency>

<dependency>
   <groupId>org.hibernate</groupId>
   <artifactId>hibernate-entitymanager</artifactId>
   <version>4.3.5.Final</version>
</dependency>
  
  
  
  La aplicación consta de 2 partes: La aplicación web, donde esté levantado el servicio REST y el cliente que lo consume, construido con JavaFX.
  
  La aplicación consta básicamente de un CRUD de clientes, que será llevada a cabo por el REST utilizando para ésto EJB's como servicios de acceso a la BBDD mediante JPA.
  
  De ésta manera, varios clientes pueden consumir el REST y hacer un CRUD sin necesidad de tener instalada una BBDD (como ocurre generalmente con los sistemas de escritorio normales).
  
  
  Imágenes
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  Demo
  
  
  
  [youtube=640,360]https://www.youtube.com/watch?v=yCH3QO7VWyU[/youtube]
  
  
  Código fuente
  
  
  Todo el código así como los WAR y JAR están en mi cuenta de Github: REST-FX-CustomersApp.

[Proceder]

Todos sabemos que no es buena idea tener temas duplicados de un foro en la BBDD. Se me ocurrió que cuando el usuario cree un nuevo tema lo rediriga a una página de confirmación que contenga lo siguiente:

• Un párrafo en la parte superior donde se informe que antes de publicar un nuevo tema, es recomendable buscar en el foro temas iguales o parecidos que puedan ayudar con su problema para así, evitar redundancia.
  
  
• Abajo del párrafo un buscador con autocompletado de búsqueda para que el usuario pueda ver los resultados de la búsqueda en tiempo real y no tener que salir de la página de confirmación. Bastante sencillo de hacer con AJAX.
  
  
• Abajo un texto que diga: He buscado y no he encontrado temas parecidos junto con un checkbox para confirmar y que se active un botón llamado Proceder, el cual lo llevará a el formulario de pregunta normal.
  
  
  Creo que así se evitarían muchos temas duplicados y preguntas rompe cojones como "¿Cómo ser hacker?" o "¿Qué lenguaje de programación aprender?"
  
  En caso el usuario no busque y cree adrede un tema duplicado creo que los mods no tendrán ningún inconveniente para pedir un ban temporal para el usuario.
  
  
  Un saludo.

Les comparto un bonito formulario de ingreso que hice para un tuto de Java EE. Me basé en éste PSD:

HTML:

Código (html4strict) [Seleccionar] Expandir

<!DOCTYPE html>
<html lang="es">
<head>
<meta charset="UTF-8"/>
<title>Identfíquese</title>
<link rel="stylesheet" href="http://maxcdn.bootstrapcdn.com/font-awesome/4.3.0/css/font-awesome.min.css"/>
<link rel="stylesheet" href="assets/css/login.css"/>
</head>
<body>
<div id="flogin" class="flogin">
       <section class="left-side">
           <section class="head">
               LOGIN
           </section>
           <section class="body">
               <section class="data">
                   <section class="form-group">
                       <span>Usuario:</span>
                       <section class="input-wrapper">
                           <input type="text" id="txt-username" class="txt"/>
                           <i class="fa fa-user"></i>
                       </section>
                   </section>
                   <section class="form-group">
                       <span>Contraseña:</span>
                       <section class="input-wrapper">
                           <input type="password" id="txt-password" class="txt"/>
                           <i class="fa fa-key"></i>
                       </section>
                   </section>
               </section>
               <section class="help">
                   <a href="">¿Olvidaste tu usuario o contraseña?</a>
               </section>
           </section>
       </section>
       <section id="btn-login" class="right-side">
           <i class="fa-4x fa fa-arrow-right"></i>
           <span>IR</span>
       </section>
   </div>

</body>
</html>

CSS:

Código (css) [Seleccionar] Expandir

.flogin {
   display: flex;
   justify-content: space-between;
   width: 400px;
}
.flogin > .left-side {
   background-color: #363636;
    /*background: radial-gradient(#555, #363636, #363636);*/
    box-shadow: 0px 0px 20px 20px #2e2e2e inset;
    border: 9px solid #dedede;
    border-right: none;
    border-radius: 20px 0px 0px 20px;
    width: 80%;
}
.flogin  > .right-side {
   align-items: center;
   background-color: #34B5D5;
   border: 9px solid #dedede;
   border-left: none;
   border-radius: 0px 20px 20px 0px;
   display: flex;
   flex-flow: column nowrap;
   justify-content: space-between;
   padding: 1.3rem .2rem;
   width: calc(20% - 2*.2rem - 9px);
}
.flogin > .right-side:hover {
   cursor: pointer;
}

/*********************
     LEFT SIDE
*********************/
.left-side > .head {
   border-bottom: 2px dashed #ddd;
   color: #eee;
   font-family: "segoe ui";
   margin-bottom: 20px;
   padding: .75rem 1rem;
}
.left-side > .body {
   padding: .8rem 1.35rem;
   width: calc(100% * 2*1.35rem);
}
.body > .data {
   display: flex;
   justify-content: space-between;
}
.form-group {
   width: 45%;
}
.form-group > span {
   color: #ddd;
   display: block;
   font-family: "segoe ui";
   font-size: 10pt;
   margin-bottom: 7px;
}
.form-group > .input-wrapper {
   align-items: center;
   background-color: white;
   border-radius: 5px;
   box-shadow: 0px 2px 5px 1px rgba(0,0,0,.4) inset,
       0px -1px 2px 1px rgba(0,0,0,.25) inset;
   display: flex;
   justify-content: space-between;
}
.input-wrapper > .txt {
   width: 80%;
}
.input-wrapper > i {
   color: gold;
   width: 20%;
}
.txt {
   background-color: transparent;
   border: none;
   border-radius: 5px;
   padding: .4rem .25rem;
   width: calc(80% - 2*.35rem - 2*1px);
}
.txt:focus {
   outline: none;
}
.help {
   display: flex;
   justify-content: flex-end;
}

a {
   color: #ddd;
   display: block;
   font-family: "segoe ui";
   font-size: 10pt;
   font-style: italic;
   margin-top: 20px;
   text-align: right;
   text-decoration: none;
}

/*****************
   RIGHT SIDE
*****************/
.right-side > i {
   color: #fff;
   display: block;
}
.right-side > span {
   color: #fff;
   display: block;
   font-family: "segoe ui";
   font-size: 16pt;
}

Resultado:

Saludos.

[SERVLETS Y AJAX]

SERVLETS Y AJAX

El presente pequeño tutorial, tiene como finalidad mostrar cómo interactuar entre Servlets y javascript, mediante AJAX, tomando como ejemplo un formulario de ingreso.

Se asume que el lector tiene noción de las siguientes tecnologías:

• Lenguaje de programación Java
  
• HTTP
  
• Servlets
  
• javascript
  
• AJAX
  
  Si no se tiene nociones de las mencionadas tecnologías, se puede seguir el tutorial, ya que se explicarán algunos puntos. De todas maneras, el lector debe de investigar cada punto, término, trozo de código o afines que no entienda.
  
  Herramientas necesarias
  
  Para seguir perfectamente éste tutorial, se necesitarán las siguientes herramientas:
  
  
• Eclipse Luna EE: IDE para programación en Java Enterprise Edition. No solo soporta el API estándar de Java, si no que también nos brinda soporte para la API empresarial.
  
• NetBeans Java EE. Gran IDE con muy buen soporte para Java Enterprise Edition. Excelente editor de código y muy buen auto completado.
  
• GlassFish: Servidor para aplicaciones Java web.
  
• org.json.jar: Librería que nos permite transformar un Map o String a JSONObject y viceversa.
  
  
  
  Zona de descargas
  
  
  • Eclipse Luna EE
  • NetBeans EE
  • GlassFish
  • Java JSON
  
  
  
  Notas de aclaración
  
  Dada la simpleza que requiere éste tutorial, NO se empleará un gestor de base de datos. El objetivo del presente documento es mostrar de forma práctica y sencilla, la comunicación entre servlets y AJAX.
  
  
  CONFIGURACIÓN DE ECLIPSE E INSTALACIÓN DE GLASSFISH
  
  
  Instalación de GlassFish Tools en Eclipse
  
  Abrimos nuestro Eclipse Luna EE. Si es primer uso, se preguntará dónde desea que sea el espacio de trabajo, por defecto es en la carpeta de usuario pero se puede especificar donde se desea (siempre y cuando tengamos permisos).
  
  Una vez abierto Eclipse, tenemos que instalar GlassFish Tools para poder instalar nuestro servidor GlassFish. Para ésto vamos a la opción Eclipse Marketplace del menú Help y buscamos "glassfish":
  
  
  
  
  Hacemos click en Install. Nos preguntará si aceptamos la licencia, elejimos el radio button "Yes. I accept..." y empezará a instalar GlassFish Tools (Si pregunta algo durante la instalación, dale "Yes"). Al finalizar la instalación nos pedirá reiniciar Eclipse. Aceptamos.
  
  Instalación de GlassFish 4.1
  
  Descomprimimos el zip que nos hemos bajado de la web de GlassFish y lo colocamos en:
  
  

  C://program Files/

  
  De tal modo que la instalación de GlassFish quede así:
  
  

  C://program Files/glassfish/

  
  Abrimos Eclipse y nos dirigimos hacia la opción Preferences del menú Window. Aquí desplegamos el menú Server -> Runtime Environments:
  
  
  
  
  Hacemos click en Add y nos mostrará una ventana con los adaptadores de servidores disponibles. Escogemos GlassFish 4 y hacemos click en Next:
  
  
  
  
  En la siguiente cara, tendremos que especificar la dirección de la instalación de GlassFish y el JDK:
  
  
  
  
  NOTA: Es bien importante que el elemento en "Java development kit" sea el JDK y no el JRE. Si les aparece JRE deben de agregar un nuevo "installed JRE" dentro de Java -> Installed JREs. Para ésto solo basta hacer click en Add y agregar la ruta del JDK de Java.
  
  Por último hacemos click en Next, dejamos todo por defecto y hacemos click en Finish para finalizar. Ya tenemos nuestro IDE listo para empezar a programar.
  
  
  INSTALAR NETBEANS Y GLASSFISH
  
  
  Al momento de instalar NetBeans Java EE, GlassFish viene incorporado. También Tomcat, pero pueden elegir no instalarlo sacando el checkbox de Tomcat 8:
  
  
  

Cuando un compañero detecta un bug en mi código



Cuando tu supervisor va a verte luego de un bug crítico en tu último commit



¿Hiciste tú el cambio que rompió el servidor en producción?



Todo funciona en desarrollo, vamos a ponerlo en producción



Cuando un comando mal hecho borra ficheros importantes en producción



Intentando parar un bucle infinito



Cuando ves lo que han prometido los de Marketing



Con tu chica luego de programar 3 días seguidos



Cuando el cliente dice que quiere "un pequeño cambio"



Cuando descubres que las contraseñas en la BBDD están en texto plano



Cuando tus compañeros miran el log del servidor y se dan cuenta que la caída es por tu culpa



Cuando el cliente te pide que hagas su web en flash xDD



Probando si tu App es compatible con IE6




Fuente: Iteramos.com

Personalmente siempre me agradó el arte del tattoo, pero nunca vi uno como éstos.

Buenas tardes,

He tratado de eliminar mi website de mi perfil pero sigue persistida. ¿Bug o así lo han programado?

[Standar, Enterprise o Cluster]

Quisiera saber cómo aplica la licencia de MySQL en software comercial. Según he investigado, si quiero usar MySQL en software comercial debo de adquirir una licencia comercial, sea Standar, Enterprise o Cluster:

¿Esto es así, o me equivoco?

NOTA: Primero aclarar que no discrimino a ningún ser humano por sus opciones. Aunque quizás algunas no me parezcan, siempre las respeto.

Siempre me ha generado una duda tremenda el tema de cómo se genera la homosexualidad. Algunas personas dicen "yo nací gay", pero, ¿es posible nacer gay?

Algunos estudios, como el que muestran en éste enlace, dicen que científicamente, es imposible nacer gay. Entonces, si no es posible nacer gay, ¿es un comportamiento psicológico adquirido?

Otras personas dicen que es posible que un varón nazca con un desorden hormonal, provocando un mayor número de hormonas femeninas en el bebé y por consiguiente un comportamiento femenino, o lo contrario en el caso de una bebé mujer. Si éste fuera un caso real, ¿tratar el desorden del bebé podría evitar su futuro homosexualismo?

En un tema interesante. Si hay personas homosexuales en el foro podrían dar su opinión personal para aclarar.

Saludos.

[TUTORIAL JPA 2.1]

TUTORIAL JPA 2.1

El presente tutorial tiene como finalidad mostrar los aspectos básicos de la especificación de Java JPA (API de Persistencia de Java por sus siglas en inglés). Se cubrirán los aspectos más básicos de ésta API para que el lector se dé cuenta del potencial que nos ofrece y que se puede aplicar en nuestros proyectos. Así mismo,

¿QUÉ ES JPA?

Como en todo proceso de aprendizaje, primero debes saber qué es exactamente el objeto de nuestro estudio. JPA como ya dijimos es el API para la persistencia en Java, pero, ¿qué es en concreto? Bien, JPA es un ORM, aunque no propiamente. Explicaremos esto en detalle a continuación.

La Java Community Process (JCP), es la encargada de las especificaciones en Java. ¿Qué quiero decir con especificaciones? Pues, una especificación no es más que un estándar. La JCP propone un estándar y si por mayoría de votos se acepta la proposición, se designa un equipo experto para que trabaje en ella. Aquí el equipo se encarga de definir la estructura de la especificación, sus características y forma de trabajar. Pero no podemos empezar a trabajar con una especificación si no tiene una implementación. Una implementación es una representación real de dicha especificación. Es como en el mismo lenguaje, una interface vendría a ser la especificación y una clase que implemente dicha interface vendría a ser la implementación o representación. Así mismo, la JCP puede o no realizar la implementación de una especificación, como lo hizo con Servlet, JAXB, JMS, JAAS, y algunos otros.

Comprendido lo anteriormente explicado, se procede a listar las mejores implementaciones de JPA:

• Hibernate
• EclipseLink
• MyBatis

Hibernate y MyBatis se pueden usar nativamente, es decir, sin usar a JPA como interfaz o también con JPA. En éste tutorial se usará Hibernate por ser el más adoptado por los desarrolladores.

PREPARANDO NUESTRO ENTORNO DE TRABAJO

Primero que todo, vamos a disponer del siguiente material:

• JDK 8
• Eclipse Luna
• Hibernate 4.3.8 (opcional, porque usaremos Maven).
• MySQL 5.6
• MySQL JDBC (opcional, usaremos Maven).
• MySQL Workbench 6.2.5

Instalación de MySQL como servicio

Nos dirigimos a "C:\Program Files\MySQL\MySQL Server 5.6" y renombramos el archivo "my-default.ini" a "my.ini". Lo editamos y al final agregamos la línea:

Código [Seleccionar] Expandir

PERFORMANCE_SCHEMA=0

Ahora, abrimos la terminal como Administrador y nos dirigimos hacia "bin". Aquí ejecutaremos el comando:

Código [Seleccionar] Expandir

mysqld –install

Y ya tenemos MySQL instalado como servicio. Si no está corriendo lo iniciamos.

CREACIÓN DE LA BASE DE DATOS

Creación de la base de datos y la tabla Employees

Abrimos MySQL Workbench e iniciamos sesión. En el editor SQL escribimos el siguiente código para crear nuestra base de datos "jpa2_tuto" y nuestra primera tabla "employees":

[JwsChat - Minichat con WebSockets y HTML5]

JwsChat - Minichat con WebSockets y HTML5

Descripción: Éste sencillo chat demuestra lo fácil que es la comunicación bidireccional con la nueva API para WebSockets de Java EE 7 combinado con el poder de HTML5.

Funcionalidades:

• Elegir un nombre de usuario (único por sesión).
  
• Personalizar el chat eligiendo un color proveído.
  
• Desconectar/Reconectar manteniendo las preferencias.
  
• Ver la lista de usuarios conectados.
  
  
  Imágenes
  
  
  
  
  
  
  
  
  
  
  
  
  Código fuente
  
  
  El código fuente lo pueden encontrar en mi Github: JwsChat
  
  
  By Gus.

[Descripción:]

Descripción: Cada año, se invierten innumerables horas y se pierden numerosos recursos debido a código mal escrito, ralentizando el desarrollo, disminuyendo la productividad, generando graves fallos e incluso pudiendo acabar con la organización o empresa. El reconocido experto de software Robert C. Martin, junto con sus colegas de Object Mentor, nos presentan sus óptimas técnicas y metodologías ágiles para limpiar el código sobre la marcha y crearlo de forma correcta, de este modo mejorará como programador. Esta obra se divide en tres partes. La primera describe los principios, patrones y prácticas para crear código limpio. La segunda incluye varios casos de estudio cuya complejidad va aumentando. Cada ejemplo es un ejercicio de limpieza y transformación de código con problemas. La tercera parte del libro contiene una lista de heurística y síntomas de código erróneo (smells) confeccionada al crear los casos prácticos. El resultado es una base de conocimientos que describe cómo pensamos cuando creamos, leemos y limpiamos código. Imprescindible para cualquier desarrollador, ingeniero de software, director de proyectos, jefe de equipo o analista de sistemas interesado en crear código de mejor calidad. ¡El libro que todo programador debe leer!.



Si cuentas con los medios para comprar el libro, te recomiendo que lo hagas. Vale totalmente los $60 que cuesta. Si no cuentas con los medios, lo puedes descargar desde aquí (escaneado).

[FXPlayer - Reproductor MP3]

  FXPlayer - Reproductor MP3

Ya que tengo tiempo libre últimamente, estoy programando lo que se me ocurra  . Últimamente se me ha dado por programar reproductores de audio, aparte de éste hice uno en HTML5+PHP que lo dejé en Desarrollo Web por si les interesa el código.

NOTA: Si encuentran bugs, si gustan los parchan, éste reproductor fue con fines completamente de diversión

FUNCIONALIDAD

• Hay dos formas de agregar música: Por medio de archivos .mp3 o por medio de carpetas.
  
• Se puede guardar/cargar listas de reproducción (XML).
  
• Modo Aleatorio y Repeat.
  
• Lectura de metadata
  
• + para subir volumen
  
• - para bajar volumen
  
• m para mute.
  
• o para escoger directorios de música.
  
  
  
  IMÁGENES:
  
  
  
  
  
  
  
  
  
  
  
  
  DESCARGA
  
  
  
  Código fuente en mi Github: FXPLayer

[HTML5 MP3 Player]

HTML5 MP3 Player

He creado un reproductor de audio en base a la API audio de HTML5. Solo lo hice por diversión, así que tal vez haya algún bug, aunque he tratado de no dejarlos xD.

NOTA: También hace uso de PHP. El uso que hace de PHP es en unas pocas líneas. Como sabrán los navegadores no permiten que desde un servidor se pueda acceder a los archivos locales del cliente, por cuestión de seguridad. Tampoco se puede obtener la ruta absoluta de los archivos que se arrastren mediante el API de drag and drop de HTML5. Por tal motivo, se me ocurrió tener toda la música en nuestro document root de Apache:

Y con PHP escanear el directorio que se arrastre en busca de archivos .mp3. Luego, agregarlos a la lista de reproducción.

FUNCIONAMIENTO

• Para agregar música se aprovecha el API drag and drop de HTML5 para arrastrar directorios donde tengamos música.
  
  
• Para eliminar canciones de la lista de reproducción se hace click derecho sobre la canción y en el menú contextual, pulsar Eliminar (no se puede eliminar una canción que se está tocando actualmente).
  
  
• Las imágenes del reproductor se pueden descargar desde aquí.
  
  
• Se ha añadido soporte para reproducción aleatoria.
  
  
  
  IMÁGENES
  
  
  
  
  
  
  
  
  
  
  DESCARGA
  
  
  
  
  Para el que quiera modificarlo, se puede descargar desde mi Github: HTML5 MP3 player.

[PATRONES DE DISEÑO: PARTE 1]

PATRONES DE DISEÑO: PARTE 1

Los patrones de diseño son la base para la búsqueda de soluciones a problemas comunes en el desarrollo de software y otros ámbitos referentes al diseño de interacción o interfaces.
Un patrón de diseño resulta ser una solución a un problema de diseño. Para que una solución sea considerada un patrón debe poseer ciertas características. Una de ellas es que debe haber comprobado su efectividad resolviendo problemas similares en ocasiones anteriores. Otra es que debe ser reutilizable, lo que significa que es aplicable a diferentes problemas de diseño en distintas circunstancias.

Los patrones de diseño pretenden:

• Proporcionar catálogos de elementos reusables en el diseño de sistemas software.
  
• Evitar la reiteración en la búsqueda de soluciones a problemas ya conocidos y solucionados anteriormente.
  
• Formalizar un vocabulario común entre diseñadores.
  
• Estandarizar el modo en que se realiza el diseño.
  
• Facilitar el aprendizaje de las nuevas generaciones de diseñadores condensando conocimiento ya existente.
  
  Asimismo, no pretenden:
  
  
• Imponer ciertas alternativas de diseño frente a otras.
  
• Eliminar la creatividad inherente al proceso de diseño.
  
  No es obligatorio utilizar los patrones, solo es aconsejable en el caso de tener el mismo problema o similar que soluciona el patrón, siempre teniendo en cuenta que en un caso particular puede no ser aplicable. "Abusar o forzar el uso de los patrones puede ser un error".
  
  
  
  PATRÓN ADAPTER
  
  El patrón adapter nos permite ampliar la funcionalidad de una clase o interfaz adaptando objetos que no coinciden con una determinada jerarquía de clases.
  
  Convierte la interfaz de una clase en otra interfaz que el cliente espera. Adapter permite a las clases trabajar juntas, lo que de otra manera no podría hacerlo debido a sus interfaces incompatibles.
  
  Cuándo usarlo:
  
  
• Se desea usar una clase existente, y su interfaz no se iguala con la necesitada.
  
• Cuando se desea crear una clase reusable que coopera con clases no relacionadas, es decir, las clases no tienen necesariamente interfaces compatibles.
  
  
  Problema: Se nos pide adaptar un auto eléctrico a un sistema de abastecimiento de combustible para autos. Siendo que el auto eléctrico, utiliza como combustible la energía eléctrica.
  
  Solución: Utilizar el patrón Adapter para extender la funcionalidad de la interfaz adaptando el auto eléctrico.
  
  Creamos una interfaz llamada Car que representará de forma genérica a un Auto:
  
  Car.java
  
  Código (java) [Seleccionar] Expandir
  package net.elhacker.adapter;

public interface Car {

void fillTank();
default void start() {
System.out.println("Encendiendo auto...");
}
}
  
  NOTA: el método start() lo predefinimos porque será el mismo para todos las implementaciones.
  
  Ahora sus implementaciones: GasolineCar y GasCar. Representan un auto a gasolina y otro a gas.
  
  GasolineCar.java
  
  Código (java) [Seleccionar] Expandir
  package net.elhacker.adapter;

public class GasolineCar implements Car {

public GasolineCar() {
super(); // llamada al constructor padre
System.out.println("Creando un auto a gasolina...");
}

@Override
public void fillTank() {
System.out.println("Colocando gasolina...");
}
}

  
  GasCar.java
  
  Código (java) [Seleccionar] Expandir
  package net.elhacker.adapter;

public class GasCar implements Car {

public GasCar() {
super(); // llamada al constructor padre
System.out.println("Creando un auto a gas...");
}

@Override
public void fillTank() {
System.out.println("Colocando gas...");
}

}
  
  Ambos autos, GasolineCar y GasCar necesitan combustible para funcionar. Por eso, el método fillTank llena el combustible de ellos, dependiendo si es gasolina o gas.
  
  Ahora queremos añadir un auto eléctrico a nuestra jerarquía de clases.
  
  ElectricCar.java
  
  Código (java) [Seleccionar] Expandir
  package net.elhacker.adapter;

public class ElectricCar {

public ElectricCar() {
super(); // llamada al constructor padre
System.out.println("Creando un auto eléctrico...");
}

public void connect() {
System.out.println("Conectando motor a generador de electricidad...");
}
}
  
  Nos damos con la sorpresa que éste auto no coincide con nuestra jerarquía. La interfaz Car dice que todos los autos que la implementen deben tener el método fillTank. Pero, ¿Como un auto eléctrico puede llenar el tanque? ¿Cómo hacemos para adaptar éste auto a nuestra jerarquía?
  
  Un error es común es modificar la interfaz o clase abstracta. Ésto viola el principio OCP, el cual nos dice:
  

  
  Las entidades de software deben ser abiertas para ser extendidas y cerradas para no ser modificadas.

  
  Aquí toma importancia en patrón Adapter. Éste patrón nos permite ampliar la funcionalidad de una interfaz si tener que cambiar código en ella. Veamos como funciona.
  
  
  Código (java) [Seleccionar] Expandir
  package net.elhacker.adapter;

public class ElectricCarAdapter implements Car {

ElectricCar electricCar;

public ElectricCarAdapter() {
electricCar = new ElectricCar();
}

@Override
public void fillTank() {
electricCar.connect();

}

}
  
  Como vemos hemos podido adaptar nuestro auto eléctrico a nuestra interfaz Car. ¡Ahora, podemos crear tanto autos a gasolina, gas o eléctricos aplicando polimorfismo!
  
  Veamos que salida nos arroja:
  
  AdapterTest.java
  
  Código (java) [Seleccionar] Expandir
  package net.elhacker.adapter;

public class AdapterTest {

public static void main(String[] args) {
Car gasolineCar = new GasolineCar();
gasolineCar.fillTank();
gasolineCar.start();

System.out.println();

Car gasCar = new GasCar();
gasCar.fillTank();
gasCar.start();

System.out.println();

Car electricCar = new ElectricCarAdapter();
electricCar.fillTank();
electricCar.start();
}

}
  
  Salida:
  
  
  Código [Seleccionar] Expandir
  Creando un auto a gasolina...
Colocando gasolina...
Encendiendo auto...

Creando un auto a gas...
Colocando gas...
Encendiendo auto...

Creando un auto eléctrico...
Conectando motor a generador de electricidad...
Encendiendo auto...
  
  Y así podemos extender la funcionalidad de nuestra aplicación de forma sencilla y eficiente.
  
  
  
  PATRÓN FACADE
  
  Descripción: El patrón fachada viene motivado por la necesidad de estructurar un entorno de programación y reducir su complejidad con la división en subsistemas, minimizando las comunicaciones y dependencias entre éstos.
  
  Cuándo usarlo:
  
  
• Se usa para proporcionar una interfaz sencilla para un sistema complejo.
  
• Se quiere desacoplar un subsistema de sus clientes u otros subsistemas, haciéndolo mas independiente y portable.
  
• Se quiera dividir los sistemas en niveles: las fachadas serian el punto de entrada a cada nivel.
  
  Pros/contras:
  
  
• + La principal ventaja del patrón fachada consiste en que para modificar las clases de los subsistemas, sólo hay que realizar cambios en la interfaz/fachada, y los clientes pueden permanecer ajenos a ello. Además, y como se mencionó anteriormente, los clientes no necesitan conocer las clases que hay tras dicha interfaz.
  
• - Como inconveniente, si se considera el caso de que varios clientes necesiten acceder a subconjuntos diferentes de la funcionalidad que provee el sistema, podrían acabar usando sólo una pequeña parte de la fachada, por lo que sería conveniente utilizar varias fachadas más específicas en lugar de una única global.
  
  Problema: Crear una aplicación que haga tres operaciones bancarias: Crear una cuenta, depositar dinero y retirar dinero. Las operaciones deben hacerse dentro de una sola entidad que las maneje.
  
  Solución: Aplicar el patrón Facade para encapsular todos los objetos que hacen las 3 operaciones.
  
  Bank.java
  
  Código (java) [Seleccionar] Expandir
  package net.elhacker.facade;

public class Bank {

public Bank() {

}

public void createAccount(String account) {
System.out.println("Creando cuenta N° "+account);
}
}
  
  Deposit.java
  
  Código (java) [Seleccionar] Expandir
  package net.elhacker.facade;

public class Deposit {

public Deposit() {

}

public void makeDeposit(double amount, String account) {
System.out.println("Se ha depositado $"+amount+" a la cuenta "+account);
}

}
  
  Withdrawal.java
  
  Código (java) [Seleccionar] Expandir
  package net.elhacker.facade;

public class Withdrawal {

public Withdrawal() {

}

public void makeWidthdrawal(double amount, String account) {
System.out.println("Se ha retirado $"+amount+" de la cuenta "+account);
}

}
  
  Ahora, creamos nuestra clase principal:
  
  FacadeTest.java
  
  Código (java) [Seleccionar] Expandir
  package net.elhacker.facade;

public class Facade {

public static void main(String[] args) {

Bank bank = new Bank();
Deposit deposit = new Deposit();
Withdrawal withdrawal = new Withdrawal();

bank.createAccount("9343435093");
deposit.makeDeposit(2599.90, "9343435093");
withdrawal.makeWidthdrawal(699.90, "9343435093");

}

}
  
  Como vemos creamos 3 objetos los cuales se encargan de efectuar las acciones. Pero, ¿es necesario crear éstos tres objetos en éste ambito? ¿Los vamos a necesitar siempre?
  
  Una mejor idea sería encapsular éstos objetos dentro de uno solo que se encargue de realizar todas las operaciones. Éste es el propósito del patrón Facade, actuar como intermediario entre la interfaz y las funcionalidades de un sistema. Veamos como se representa:
  
  OperationsFacade.java
  
  Código (java) [Seleccionar] Expandir
  package net.elhacker.facade;

public class OperationsFacade {


public OperationsFacade() {
}

public void createAccount(String account) {
new Bank().createAccount(account);
}

public void makeDeposit(double amount, String account) {
new Deposit().makeDeposit(amount, account);
}

public void makeWithdrawal(double amount, String account) {
new Withdrawal().makeWidthdrawal(amount, account);
}

}
  
  Como podemos observar, ésta clase encapsula el comportamiento de las clases Bank, Deposit y Withdrawal. Ya no tenemos que declarar los objetos porque éstos se crean en los métodos de OperationsFacade y se destruyen al finalizar el mismo. ¡Además ahorramos memoria!
  
  Ahora, veamos como queda la clase principal:
  
  FacadeTest.java
  
  Código (java) [Seleccionar] Expandir
  package net.elhacker.facade;

public class FacadeTest {

public static void main(String[] args) {
OperationsFacade facade = new OperationsFacade();
facade.createAccount("9343435093");
facade.makeDeposit(2599.90, "9343435093");
facade.makeWithdrawal(699.90, "9343435093");
}

}
  
  Como podemos ver, solo necesitamos de un objeto OperationsFacade para realizar todas las operaciones. Así aplicamos también el principio KISS (Keep it simple stupid!).
  
  Salida:
  
  
  Código [Seleccionar] Expandir
  Creando cuenta N° 9343435093
Se ha depositado $2599.9 a la cuenta 9343435093
Se ha retirado $699.9 de la cuenta 9343435093
  
  
  PATRÓN ABSTRACT FACTORY
  
  Descripción: El patrón Abstract Factory nos permite crear, mediante una interfaz, conjuntos o familias de objetos (denominados productos) que dependen mutuamuente y todo esto sin especificar cual es el objeto concreto.
  
  Cuándo usarlo:
  
  
• Un sistema debe ser independiente de como sus objetos son creados.
  
• Un sistema debe ser 'configurado' con una cierta familia de productos.
  
• Se necesita reforzar la noción de dependencia mutua entre ciertos objetos.
  
  
  Pros/contras:
  
  
• + Brinda flexibilidad al aislar a las clases concretas.
  
• + Facilita cambiar las familias de productos.
  
• - Para agregar nuevos productos se deben modificar tanto las fabricas abstractas como las concretas.
  
  Problema: Se nos pide crear animales de X tipo sin especificar cuál es el objeto en concreto.
  
  Solución: Utilizar el patrón Abstract Factory para crear los objetos solicitados.
  
  Primero, creamos una clase abstracta llamada Animal que representará de forma genérica a un Animal:
  
  Animal.java
  
  Código (=java) [Seleccionar] Expandir
  package net.elhacker.factory;

public abstract class Animal {

protected String type;
protected String family;
protected String habitat;

public Animal(String type, String family, String habitat) {
this.type = type;
this.family = family;
this.habitat = habitat;
}

public String getType() {
return type;
}

public void setType(String type) {
this.type = type;
}

public String getFamily() {
return family;
}

public void setFamily(String family) {
this.family = family;
}

public String getHabitat() {
return habitat;
}

public void setHabitat(String habitat) {
this.habitat = habitat;
}

@Override
public String toString() {
return "Tipo de animal: "+getType()+"\nFamilia: "+getFamily()+
"\nHábitat: "+getHabitat();
}
}

  
  Y tres animales que extienden de Animal:
  
  Dog.java
  
  Código (java) [Seleccionar] Expandir
  package net.elhacker.factory;

public class Dog extends Animal {

public Dog(String type, String family, String habitat) {
super(type, family, habitat);
}

}
  
  Shark.java
  
  Código (java) [Seleccionar] Expandir
  package net.elhacker.factory;

public class Shark extends Animal {

public Shark(String type, String family, String habitat) {
super(type, family, habitat);
}


}
  
  Lion.java
  
  Código (java) [Seleccionar] Expandir
  package net.elhacker.factory;

public class Lion extends Animal {

public Lion(String type, String family, String habitat) {
super(type, family, habitat);
}


}
  
  Bien, ya tenemos nuestros 3 tipos de animales que heredan de Animal: Dog, Shark y Lion. Como la tarea es construir objetos sin especificar de qué tipo son, creamos una fábrica abstracta que especifica la creación de un Animal genérico sin especificar de qué tipo:
  
  AbstractAnimalFactory.java
  
  Código (java) [Seleccionar] Expandir
  package net.elhacker.factory;

public interface AbstractAnimalFactory {

Animal createAnimal();
}
  
  Ahora, el siguiente paso es hacer las implementaciones de ésta fábrica abstracta, es decir las fábricas concretas que crearán los objetos concretos:
  
  DogFactory.java
  
  Código (java) [Seleccionar] Expandir
  package net.elhacker.factory;

public class DogFactory implements AbstractAnimalFactory {

protected String type;
protected String family;
protected String habitat;

public DogFactory(String type, String family, String habitat) {
this.type = type;
this.family = family;
this.habitat = habitat;
}

@Override
public Animal createAnimal() {
return new Dog(type, family, habitat);
}

}
  
  SharkFactory.java
  
  Código (java) [Seleccionar] Expandir
  package net.elhacker.factory;

public class SharkFactory implements AbstractAnimalFactory {

protected String type;
protected String family;
protected String habitat;

public SharkFactory(String type, String family, String habitat) {
this.type = type;
this.family = family;
this.habitat = habitat;
}

@Override
public Animal createAnimal() {
return new Shark(type, family, habitat);
}

}
  
  LionFactory.java
  
  Código (java) [Seleccionar] Expandir
  package net.elhacker.factory;

public class LionFactory implements AbstractAnimalFactory {

protected String type;
protected String family;
protected String habitat;

public LionFactory(String type, String family, String habitat) {
this.type = type;
this.family = family;
this.habitat = habitat;
}

@Override
public Animal createAnimal() {
return new Lion(type, family, habitat);
}

}
  
  Analicemos un poco el código. Cada una de las implementaciones de AbstractAnimalFactory especifican la implementación que tendrá para crear un tipo de animal.
  
  Cada factoría concreta, tiene las 3 propiedades que necesita cada objeto para poder crearse. Así mismo, dichos datos se pasan como parámetros a su constructor para establecer los valores en las propiedades que se utilizarán para crear una instancia del objeto.
  
  Establece las propiedades:
  
  
  Código (java) [Seleccionar] Expandir
  public LionFactory(String type, String family, String habitat)
  
  Y usa esas mismas propiedades para crear el objeto:
  
  
  Código (java) [Seleccionar] Expandir
  @Override
public Animal createAnimal() {
return new Lion(type, family, habitat);
}
  
  Finlamente, se sobre-escribe el método de la factoría abstracta createAnimal() para retornar un nuevo objeto de acuerdo al tipo de factoría. Así, la factoría de Perros, creará objetos tipo Perro, la factoría de Tiburones creará objetos tipo Tiburón y la factoría de Leones, crearán objetos tipo León.
  
  Por último, especificamos una Fábrica global que utilizará las 3 fábricas para crear los objetos (Aquí se aplica también el patrón Facade):
  
  AnimalFactory.java
  
  Código (java) [Seleccionar] Expandir
  package net.elhacker.factory;

public abstract class AnimalFactory {

public static Animal create(AbstractAnimalFactory factory) {
return factory.createAnimal();
}
}
  
  Ésta clase recibe un objeto que implemente la interfaz AbstractAnimalFactory, por lo tanto podrá recibir objetos tipo: DogFactory, SharkFactory y LionFactory. Luego simplemente usa la factoría especificada para crear un animal mediante polimorfismo.
  
  Ahora construyamos nuestra clase principal para probar el funcionamiento del patrón:
  
  FactoryTest.java
  
  Código (java) [Seleccionar] Expandir
  package net.elhacker.factory;

public class FactoryTest {

public static void main(String[] args) {
Animal dog = AnimalFactory.create(new DogFactory("Perro","Caninos","Doméstico"));
Animal shark = AnimalFactory.create(new SharkFactory("Tiburón", "Lámnidos", "Mar"));
Animal lion = AnimalFactory.create(new LionFactory("León", "Felinos", "Selva"));

System.out.println(dog.toString());
System.out.println();
System.out.println(shark.toString());
System.out.println();
System.out.println(lion.toString());
}
}
  
  Utilizamos el método estático create() de AnimalFactory que recibe una implementación de la interfaz AbstractAnimalFactory, en éste caso un objeto DogFactory al que se le asignan los valores "Perro", "Caninos" y "Doméstico" y finalmente AnimalFactory llama al método createAnimal() de DogFactory para crear un animal tipo Dog y devolverlo hacia AnimalFactory que lo devuelve y lo guarda en el objeto 'dog'. El mismo procedimiento es para todas las factorías.
  
  Salida:
  
  
  Código [Seleccionar] Expandir
  Tipo de animal: Perro
Familia: Caninos
Hábitat: Doméstico

Tipo de animal: Tiburón
Familia: Lámnidos
Hábitat: Mar

Tipo de animal: León
Familia: Felinos
Hábitat: Selva
  
  Y de ésta manera sencilla, podemos usar tantas fábricas como queramos para poder crear objetos si generar dependencias
  
  
  PATRÓN SINGLETON
  
  Cuándo usarlo:
  
  
• Cuando la aplicación requiere que solo exista una instancia de un determinado objeto.
  
  Problema: Encapsular la configuración de una aplicación en un objeto y compartirlo con los demás objetos de la aplicación que lo requiera.
  
  Solución: Utilizar el patrón Singleton para encapsular la configuración de la aplicación.
  
  Para utilizar éste patrón se deben seguir dos reglas:
  
  
• El primer paso es hacer el constructor privado para que no se pueda llamar y por lo tanto, no se puedan crear instancias.
  
• El segundo paso es crear una instancia de la clase y devolverla mediante un método estático.
  
  Teniendo en cuenta éstas reglas, creamos una clase que representa a la configuración de la aplicación:
  
  Configuration.java
  
  Código (java) [Seleccionar] Expandir
  package net.elhacker.singleton;

import java.util.HashMap;
import java.util.Map;

public class Configuration {

private Map<String,Object> appOptions = null;
private static Configuration config;

private Configuration() {

}

public static Configuration getConfiguration() {
if(config == null) {
config = new Configuration();
}
return config;
}

public Map<String,Object> getAppOptions() {
if(appOptions == null) {
appOptions = new HashMap<>();
appOptions.put("theme", "dark");
appOptions.put("show_hidde_files", true);
}
return appOptions;
}

public void setAppOptions(Map<String,Object> appOptions) {
this.appOptions = appOptions;
}

}
  
  Y simplemente, cuando la necesitemos, obtenemos su única instancia:
  
  SingletonTest.java
  
  Código (java) [Seleccionar] Expandir
  package net.elhacker.singleton;

import java.util.Map;

public class SingletonTest {

public static void main(String[] args) {
Configuration cfg = Configuration.getConfiguration();

               // recorre el hashmap para leer las claves y valores
for(Map.Entry<String, Object> entry: cfg.getAppOptions().entrySet()) {
System.out.println(entry.getKey()+": "+entry.getValue());
}

}

}
  
  Salida:
  
  
  Código [Seleccionar] Expandir
  show_hidde_files: true
theme: dark
  
  
  NOTA IMPORTANTE:
  
  Generalmente, cuando se usa éste patrón, se garantiza que solamente existirá una instancia de dicha clase. Pero, si se trata de una aplicación web y se va a integrar una aplicación web con otra, es probable que ya no exista una sola instancia.
  
  Ésto se debe a los ClassLoaders. Cada contenedor de cada aplicación web (WAR) tiene su propio ClassLoader, por lo que en el supuesto caso de una integración de WARs, las instancias serán dos y no una como se había previsto.
  

[PARTE 1: PREPARACIÓN DEL IDE (ECLIPSE)]

PARTE 1: PREPARACIÓN DEL IDE (ECLIPSE)

AJAX

AJAX (Asynchronous javascript And XML), es una tecnología que es muy usada en el desarrollo de sitios o aplicaciones web. Ésta tecnología nos permite mostrar, recargar contenido sin necesidad de refrescar toda la página web.

Esto es muy útil, sobre todo desde el punto de vista de rendimiento ya que, de la forma normal cuando se recarga toda la página, se vuelven a realizar todas las peticiones que ya han sido mandadas, como son peticiones a tu hoja de estilos, a tus scripts JS, fuentes, librerías. Por otro lado, con AJAX, solo se recarga la parte que se desea.

HIBERNATE

Hibernate es un framework ORM (Object Relational Mapping). Un ORM es una aplicación que nos permite "mapear" nuestras tablas y mostrarlas en nuestra aplicación como "objetos" (Si no sabes qué es un objeto lee primero sobre POO y vuelve cuando ya hayas asimilado los conceptos).

Cuando trabajamos con un ORM, nosotros ya no tenemos que preocuparnos por iniciar la conexión, cerrarla ni construir sentencias SQL. El ORM lo hace por nosotros. Alternativamente, Hibernate nos permite utilizar "NamedQueries" que son sentencias HQL (Hibernate Query Language) y poder llamarlas cuando las necesitemos.

LEVANTAMIENTO DEL PROYECTO

Herramientas:

• Eclipse Luna JEE
  
• MySQL 5.6
  
• Hibernate 4.3.8
  
• Java-JSON
  
• jBCrypt
  
  Creamos una tabla en MySQL llamada "users4login" en nuestra BBDD. Ésta tabla tendrá los siguientes atributos (vamos a mantenerlo simple):
  
  
  Código (sql) [Seleccionar] Expandir
  CREATE TABLE users4login
(
  `user_id` int auto_increment not null,
  `username` varchar(45) not null,
  `email` varchar(90) not null,
  `password` varchar(255) not null,
  CONSTRAINT pk_user PRIMARY KEY(`user_id`)
);
  
  A continuación ingresamos los siguientes datos:
  
  Código [Seleccionar] Expandir
  
username: Duke
email: duke@localtest.me
password: 12345 (hasheado en BCrypt):
$2a$10$1Yf2nGEJWacanDyfftzpru8vcy4L5bOB6ohJ9bG4FeSg1T568DGWa
  
  
  PREPARACIÓN DEL ENTORNO
  
  Registrar el driver MySQL en Eclipse:
  
  Nos dirigimos a Eclipse y clickeamos en:
  
  
  Código [Seleccionar] Expandir
  Window -> Preferences.
  
  Se abrirá una ventana con muchas opciones. Nos dirigimos a:
  
  
  Código [Seleccionar] Expandir
  Data Management -> Conectivity -> Driver definitions
  
  Seleccionamos Add y se nos abrirá la siguiente ventana:
  
  
  
  Desplegamos el combo "Vendor Filter" y seleccionamos "MySQL". Escojemos la versión 5.1. Ahora, nos dirigmos a la pestaña "JAR list".
  Aquí hacemos click en "Add JAR/Zip" y nos mostrará un diálogo para seleccionar el conector jdbc para MySQL. Navegamos hacia donde tengamos el conector y lo seleccionamos. Una vez seleccionado el conector, hacemos clic en "OK".
  
  NOTA: Si no tenemos el conector, lo podemos bajar de Aquí.
  
  
  
  CREACIÓN DE UN DATA SOURCE
  
  Nos dirigimos hacia "data source explorer" en Eclipse y en "Database Connections" hacemos click derecho y seleccionamos "New..".
  
  
  
  En la ventana que nos mostrará, podemos ver todos los gestores de bases de datos. Seleccionamos MySQL y le colocamos el nombre "Users_Test". Damos click en "Next". Por último, colocamos los datos de nuestra BBDD y le damos finish:
  
  
  
  
  
  REGISTRAR UN SERVIDOR DE APLICACIONES (TOMCAT)
  
  Nos dirigimos a:
  
  
  Código [Seleccionar] Expandir
  Window -> Preferences -> Server -> Runtime enviroments
  
  
  
  En la siguiente pantalla, solo indicamos la ruta donde tenemos descomprimido Tomcat 8 y le damos finish.
  
  NOTA: Si no lo tienes, lo puedes descargar desde Aquí.
  
  Aceptamos todo y nos dirigimos en la pestaña Servers del panel derecho. Aquí damos click derecho en el panel y seleccionamos:
  
  
  Código [Seleccionar] Expandir
  New -> Server
  
  
  
  Y finalmente, seleccionamos nuestro servidor Tomcat 8 que hemos registrado y le damos finish:
  
  
  
  Ya tenemos listo nuestro IDE para poder trabajar.
  
  
  
  
  PARTE 2: CREACIÓN Y EJECUCIÓN DEL PROYECTO
  
  
  Nos dirigimos a:
  
  
  Código [Seleccionar] Expandir
  New -> Project -> JPA Project
  
  Le colocamos el nombre "LoginDemo". Escojemos nuestro servidor Tomcat 8, hacemos click en "Modify" y seleccionamos lo siguiente:
  
  
  
  Aceptamos y damos click en Next. Aquí nos pedirá la conexión a la BBDD para poder mapear las tablas a clases. Seleccionamos nuestra conexión y Next:
  
  
  
  Debe quedar así. Por último, en la siguiente pantalla seleccionamos la casilla "Generate web xml deployment descriptor" y le damos finish.
  
  Nuestro proyecto debe verse así:
  
  
  
  Dentro de WEB-INF hay una carpeta lib. Ésta carpeta contiene las librerías que necesita la aplicación, por lo tanto, añadimos las librerías de Hibernate, MySQL, JSON y BCrypt (éstas dos últimas las veremos más adelante). Debe quedar así:
  
  
  
  Al estar en esta carpeta, Eclipse automáticamente las agrega al classpath.
  
  Ahora, necesitamos especificar la configuración de nuestra conexión a la BBDD. El archivo persistence.xml queda así:
  
  
  Código (xml) [Seleccionar] Expandir
  <?xml version="1.0" encoding="UTF-8"?>
<persistence version="2.1" xmlns="http://xmlns.jcp.org/xml/ns/persistence"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/persistence http://xmlns.jcp.org/xml/ns/persistence/persistence_2_1.xsd">

<!--  nombre de nuestra persistencia y tipo de transacción (local) -->
<persistence-unit name="LoginDemo" transaction-type="RESOURCE_LOCAL">
   
   <!-- proveedor jpa - hibernate -->
   <provider>org.hibernate.jpa.HibernatePersistenceProvider</provider>
   
   <!-- configuracion -->
   <properties>
     <property name="javax.persistence.jdbc.url" value="jdbc:mysql://localhost:3306/test_db"/>
     <property name="javax.persistence.jdbc.user" value="usuario"/>
     <property name="javax.persistence.jdbc.driver" value="com.mysql.jdbc.Driver"/>
     <property name="javax.persistence.jdbc.password" value="contra"/>
     <property name="dialect" value="org.hibernate.dialect.MySQL5Dialect"/>
     <property name="hibernate.hbm2ddl.auto" value="update"/>
     <property name="hibernate.cache.provider_class" value="org.hibernate.cache.NoCacheProvider"/>
     <property name="show_sql" value="true"/>
   </properties>
   
</persistence-unit>
</persistence>
  
  
• Primero le damos un nombre a la unidad de persistencia, en éste caso LoginDemo.
  
• Indicamos el proveedor de la persistencia. En éste caso Hibernate.
  
• Indicamos la configuración de la conexión.
  
  Hay que prestar especial atención en el atributo name de persistence-unit. El nombre que le pongas, será el que debes especificar más adelante cuando inicialices Hibernate.
  
  NOTA: Las siguientes líneas dependen de tu usuario en MySQL y tu contraseña:
  
  
  Código (xml) [Seleccionar] Expandir
  <property name="javax.persistence.jdbc.user" value="usuario"/>
<property name="javax.persistence.jdbc.password" value="contra"/>
  
  Una vez hecho esto, procedemos a mapear nuestra tabla users4login a una clase.
  
  MAPEO DE TABLAS
  
  Primero creamos un paquete:
  
  
  Código [Seleccionar] Expandir
  Click derecho en src -> New-> Package
  
  Le colocamos el nombre: com.mycompany.models.entities
  
  Luego, mapeamos nuestra tabla a una clase:
  
  
  Código [Seleccionar] Expandir
  Click derecho en com.mycompany.model.entities -> New-> JPA entities from tables
  
  Veremos la siguiente ventana. Aquí seleccionamos nuestra conexión y las tablas a mapear:
  
  
  
  Finalmente damos click en Finish. Y se nos creará una clase. Vamos a modifcarla un poco, y quedará así:
  
  
  Código (java) [Seleccionar] Expandir
  package com.mycompany.models.entities;

import java.io.Serializable;
import javax.persistence.*;


/**
* The persistent class for the users4login database table.
*
*/
@Entity
@Table(name="users4login")
@NamedQueries({
@NamedQuery(name="Users4login.findAll", query="SELECT u FROM User u"),
@NamedQuery(name="Users4login.findUser", query = "SELECT u FROM User u WHERE u.username = :username OR u.email = :username")
})
public class User implements Serializable {
private static final long serialVersionUID = 1L;

@Id
@Column(name="user_id",nullable=false)
@GeneratedValue(strategy = GenerationType.IDENTITY)
private int userId;

@Column(name="email",nullable=false)
private String email;

@Column(name="password",nullable=false)
private String password;

@Column(name="username",nullable=false)
private String username;

public User() {
}

public int getUserId() {
return this.userId;
}

public void setUserId(int userId) {
this.userId = userId;
}

public String getEmail() {
return this.email;
}

public void setEmail(String email) {
this.email = email;
}

public String getPassword() {
return this.password;
}

public void setPassword(String password) {
this.password = password;
}

public String getUsername() {
return this.username;
}

public void setUsername(String username) {
this.username = username;
}

}
  
  Aquí voy a explicar algunas cosas:
  
  
• @Table: hace referencia a la tabla en la BBDD y el atributo name indica el nombre de la tabla. Por ésta, razón le podemos poner el nombre que queramos a la clase. Para hacerlo más sencillo, se lo he cambiado por "User" en lugar de "Users4login".
  
• @Entity: indica que dicha clase es una entidad.
  
• @Id: Indica que dicho campo es la llave primaria.
  
• @GeneratedValue: indica el tipo de generación, en éste caso GenerationType.IDENTITY, indica que la llave primaria tendrá un generador AUTO_INCREMENT en MySQL.
  
• @Column: indica que dicho campo es una columna en la base de datos. El atributo name, indica el nombre de la columna y nullable, si el campo puede recibir null.
  
• @NamedQuery: especifica una consulta a la base de datos y se identifica con un nombre (atributo name).
  
  Una vez explicado éstos conceptos, creamos un paquete llamado com.mycompany.util. Dentro de éste paquete, creamos una clase llamada EntityManagerUtil:
  
  
  Código (java) [Seleccionar] Expandir
  package com.mycompany.util;

import javax.persistence.EntityManagerFactory;
import javax.persistence.Persistence;

/**
*
* @author Gus
*/
public class EntityManagerUtil {
   
private static final EntityManagerFactory emf = Persistence.createEntityManagerFactory("LoginDemo");

   private EntityManagerUtil() {
   
   }
   
   public static EntityManagerFactory getEntityManagerFactory()
   {
       return emf;
   }
}
  
  Lo que hace ésta clase es leer el archivo persistence.xml y a partir de él, crear una factoría de EntityManager. EntityManager, como su nombre lo indica, es el encargado de administrar entidades (leer, persistir, actualizar, eliminar).
  
  Aquí es cuando el atributo name del persistence-unit del archivo persistence.xml tiene importancia. "LoginDemo", es el nombre que le hemos puesto al persistence-unit, por lo tanto, debemos indicárselo en el método createEntityManagerFactory().
  
  En ese mismo paquete, creamos una nueva clase llamada UserUtil, la cual hará las consultas a la BBDD para comprobar si un usuario existe en la tabla.
  
  
  Código (java) [Seleccionar] Expandir
  package com.mycompany.util;

import java.util.List;

import javax.persistence.*;

import com.mycompany.models.entities.User;

/**
*
* @author Gus
*/
public class UserUtil {
   
   public static User getUser4login(String username)
   {
       EntityManager em = null;
       User user = null;
       
       /**
        * @description Obtenemos el EMF y a continuación el EM. Luego iniciamos una
        * transacción (em.getTransaction().begin()). Posteriormente cargamos la NamedQuery
        * que creamos en la clase 'User', y le asignamos el parámetro ':username' (es equivalente
        * al '?' de las sentencias preparadas), en este caso el nombre de usuario/email que recibe
        * por parámetro. Ejecuta la sentencia y guarda - si encuentra - el usuario en la variable 'user'.
        * Finalmente termina la transacción.
        * @error Pueden ocurrir dos errores: Un error al obtener el EM o al no encontrarse el usuario.
        * @after Cerramos la conexión del EM y devolvemos la varianle 'user'.
        */
       try
       {
           em = EntityManagerUtil.getEntityManagerFactory().createEntityManager();
           em.getTransaction().begin();
           Query query = em.createNamedQuery("User.findUser",User.class);
           query.setParameter("username", username);
           @SuppressWarnings("unchecked")
List<User> users = (List<User>) query.getResultList();
           if(!users.isEmpty())
            user = (User) users.get(0);
           em.getTransaction().commit();
       }
       catch (Exception ex)
       {
        ex.printStackTrace();
           try { throw new Exception("Ha ocurrido un error: "+ex.getMessage());}
           catch (Exception e) {
            if(em.getTransaction().isActive())
            em.getTransaction().rollback();
           }
       }
       finally
       {
           if(em != null && em.getTransaction().isActive()) {
               em.close();
           }
       }
       return user;
   }
}

  
  Ahora bien, ¿Cómo trabaja JPA y qué significa éste código? A continuación, paso a explicarlo:
  
  Éste método recibe como parámetro un nombre de usuario o email. A continuación, creamos un objeto tipo EntityManager (el cual ya expliqué más arriba su propósito) y un objeto tipo User para devolverlo en caso hayan coincidencias.
  
  Dentro del try, hago una llamada al método estático getEntityManagerFactory() de la clase EntityManagerUtil, el cual me devuelve una instancia tipo EntityManagerFactory, seguidamente contateno ésta llamada al método propio de EntityManagerFactor, getEntityManager(), el cual me devolverá una instancia de tipo EntityManager para poder manejar entidades (entidad User en nuestro caso).
  
  Obtengo una instancia Transaction del objeto EntityManager (em.getTransaction()) e inicio una nueva transacción llamando al método begin de Transaction (em.getTransaction().begin()). Listo, tengo mi transacción lista para realizar operaciones.
  
  Creo una NamedQuery con la NamedQuery que creamos en la entidad User. El método createNamedQuery recibe dos parámetros: El nombre de la NamedQuery y la entidad propietaria. Por ésta razón, seguido del nombre de la NamedQuery le pasamos la clase User (User.class). Éste método devuelve un objeto Query construido con los parámetros enviados listo para realizar la consulta.
  
  Antes de realizar una consulta con un Query, necesitamos establecer los valores que hemos dejado en "duda" en nuestra NamedQuery de la entidad User:
  
  
  Código (java) [Seleccionar] Expandir
  @NamedQuery(name="Users4login.findUser", query = "SELECT u FROM User u WHERE u.username = :username OR u.email = :username")
  
  Lo que es equivalente a un PreparedStatement o a un stmt en PHP:
  
  
  Código (java) [Seleccionar] Expandir
  String query = "SELECT * FROM User u WHERE u.username = ? OR u.email = ?";
ps.setString(1,"usuario");
ps.setString(2,"email@algo.com");
  
  PHP:
  
  
  Código (php) [Seleccionar] Expandir
  Stmt.Bind_param("ss","username","email@algo.com");
  
  Tomar atención que la NamedQuery no hace referencia al nombre de la tabla, si no al nombre de la clase, porque la clase hace referencia a la tabla.
  
  
• Ejecutamos la sentencia: query.getResultList(). Éste método devuelve una lista de registros de acuerdo a la consulta.
  
• Evaluamos, si la lista no está vacía guardamos en el objeto User que creamos al inicio del método, el Usuario encontrado traído de la BBDD.
  
• Por último, cerramos la transacción: em.getTransaction().commit() y retornamos el objeto User declarado al principio del método, independientemente si está null (no se encontró Usuario).
  
• En el catch, si la la conexión del EntityManager está activa, hacemos un rollback(), que es deshacer cambios.
  
• En el finally, cerramos la conexión del EntityManager, sólo si ésta está activa.
  
  En el mismo paquete, crearemos una clase llamada JSONUtil, con el siguiente código:
  
  
  Código (java) [Seleccionar] Expandir
  package com.mycompany.util;

import java.util.HashMap;
import java.util.Map;

import org.json.JSONException;
import org.json.JSONObject;

public class JSONUtil {

public static Map<String,Object> jsonToMap(String stringifyJSON)
{
JSONObject jsonObj = null;
       Map<String,Object> data = null;
       try {
jsonObj = new JSONObject(stringifyJSON);
data = new HashMap<>();

for(byte i=0; i<jsonObj.names().length(); i++)
{
data.put(jsonObj.names().getString(i), jsonObj.get(jsonObj.names().getString(i)));
}
} catch (JSONException e) {
e.printStackTrace();
}
       
       return data;
}
}
  
  Ésta clase tiene un método bien simple. Recibe un objeto JSON en tipo String, lo convierte a JSON con ayuda de la librería json-java, lo recorre y guarda los datos que tenga en un objeto Map (si vienes de PHP, imagina que son arrays asociativos).
  
  JSONObject.names() devuelve un objeto JSON con las llaves del objeto JSON. Y JSONObject.get(String key), devuelve el valor asociado a dicha llave.
  
  La estructura del proyecto hasta el momento está así:
  
  
  
  Antes de proceder:
  
  
• Crear un folder dentro de WebContent llamado resources.
  
• Dentro de resources crear 3 folders: css, js, img y vendor.
  
• Descargar jQuery 2.1.1 en su versión minificada y colocarla dentro del folder vendor.
  
• Descargar la hoja de estilos por ser un poco larga, y colocarla dentro del folder css.
  
  CSS
  
  Así quedaría nuestra estructura:
  
  
  
  
  Creamos un archivo llamado index.jsp dentro del folder WebContent:
  
  
  Código [Seleccionar] Expandir
  New -> JSP file.
  
  Éste archivo tendrá el siguiente código:
  
  
  Código (html4strict) [Seleccionar] Expandir
  <%--
   Document   : index
   Created on : 21/01/2015, 09:51:38 AM
   Author     : Gus
--%>

<%@page contentType="text/html" pageEncoding="UTF-8"%>
<!DOCTYPE html>
<html>
   <head>
       <meta charset="UTF-8">
       <link rel="stylesheet" href="resources/css/font-awesome.min.css"/>
       <link rel="stylesheet" href="resources/css/general.css"/>
       <title>Demo Login Servlet/AJAX</title>
   </head>
   <body>
       
       <section class="main-container">
           
           <header>
               <nav class="navbar">
                   <span class="header-logo"></span>
                   <h1 class="header-title">EJEMPLO LOGIN: INTEGRANDO SERVLETS Y AJAX</h1>
               </nav>
           </header>
           
           <section class="main-content">
               
               <form class="panel">
                   <section class="panel-head">
                       <span class="form-logo"></span>
                       <h1 class="panel-title">Identifíquese</h1>
                   </section>
                   <section class="panel-body">
                       <section class="form-group-hoz">
                           <label for="user">Usuario o email:</label>
                           <input type="text" id="user" name="user" class="textfield"/>
                       </section>
                       <section class="form-group-hoz">
                           <label for="pass">Contraseña:</label>
                           <input type="password" id="pass" name="pass" class="textfield"/>
                       </section>
                       <section id="error-message" class="error-message-inactive">
                        <p class="error-message-text"></p>
                       </section>
                       <section class="form-btn-group">
                           <button type="submit" class="btn btn-primary">Aceptar</button>
                           <button type="button" class="btn btn-danger">Cancelar</button>
                       </section>
                   </section>
               </form>
           </section>
           
       </section>
       
       <script src="resources/vendor/jquery-2.1.1.min.js"></script>
       <script src="resources/js/util.js"></script>
       <script src="resources/js/call_servlet_ajax.js"></script>
   </body>
</html>

  
  Lo que nos interesa es solamente el formulario. El resto, es solo para darle estilos a la página y se vea formal. En el formulario, no especificamos el método ni el archivo que procesará la acción. Esto lo haremos posteriormente con AJAX.
  
  Podemos ver 2 elementos tipo input, uno para el usuario y otro para la contraseña y le colocamos un id cada uno para poder identificarlos:
  
  
  Código (html4strict) [Seleccionar] Expandir
  <input type="text" id="user" name="user" class="textfield"/>
<input type="password" id="pass" name="pass" class="textfield"/>
  
  También contiene dos botones: Uno para enviar los datos del formulario y otro para limpiar.
  
  
  Código (html4strict) [Seleccionar] Expandir
  <button type="submit" class="btn btn-primary">Aceptar</button>
<button type="reset" class="btn btn-danger">Limpiar</button>
  
  
  
  CREACIÓN DEL ARCHIVO javascript (AJAX)
  
  Creamos un archivo javascript llamado call_servlet_ajax.js dentro del folder resources/js. Éste archivo tendrá el siguiente código.
  
  
  Código (javascript) [Seleccionar] Expandir
  /**
* @author Gus
*/
$("form").on("submit", function(e)
{
// previene el submit normal del formulario
e.preventDefault();

var username = $("#user").val();
var pass = $("#pass").val();

var dataToSend = '{"username": "'+username+'", "password": "'+pass+'"}';

$.ajax(
{
url: "LoginController",
data: { data: dataToSend },
dataType: "json",
type: "post"
})
.done(function(data)
{
console.log("SUCCESS");
$("#error-message > p").html(data["message"]);
$("#error-message > p").removeClass("error-message-text").addClass("success-message-text");
$("#error-message > p").css("padding",".25rem");
if($("#error-message").hasClass("error-message-inactive")) {
$("#error-message").removeClass("error-message-inactive").addClass("error-message-active");
}
})
.fail(function(jqXHR, textStatus, errorThrown)
{
var response = JSON.parse(jqXHR.responseText);
console.log("FAIL");
$("#error-message > p").html(response["message"]);
$("#error-message > p").removeClass("success-message-text").addClass("error-message-text");
$("#error-message > p").css("padding",".25rem");
$("#error-message").removeClass("error-message-inactive").addClass("error-message-active");
})
.always(function(jqXHR, textStatus, errorThrown) {
$("#loading-icon").removeClass("fa fa-circle-o-notch fa-spin");
});
});

  
  Primero obtenemos los valores escritos en los input. Seguidamente creamos un objeto JSON con dichos valores.
  
  En la llamada AJAX, en la url deben poner el nombre del servlet (sin la barra al inicio), para indicar que dicho servlet manejará la petición. En data, creamos un JSON con un parámetro "data" y su valor el String con forma de JSON "dataToSend", especificamos que se va a trabajar con json y que el método será POST.
  
  
  
  CREACIÓN DEL SERVLET
  
  Creamos un paquete llamado com.mycompany.controllers.servlets. Dentro de éste paquete crearemos un Servlet:
  
  
  Código [Seleccionar] Expandir
  New -> Servlet
  
  Y lo pondremos el nombre LoginController. Damos finish. Colocamos el siguiente código en el Servlet:
  
  
  Código (java) [Seleccionar] Expandir
  package com.mycompany.control.servlets;

import java.io.IOException;
import java.io.PrintWriter;
import java.util.HashMap;
import java.util.Map;

import javax.servlet.ServletException;
import javax.servlet.annotation.WebServlet;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

import org.json.JSONObject;
import org.mindrot.jbcrypt.BCrypt;

import com.mycompany.models.entities.User;
import com.mycompany.util.JSONUtil;
import com.mycompany.util.UserUtil;


@WebServlet(asyncSupported = true, urlPatterns = { "/LoginController" })
public class LoginController extends HttpServlet {
private static final long serialVersionUID = 1L;
     

   public LoginController() {
       super();    
   }

protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {

}

protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {

response.setContentType("application/json");
       PrintWriter writer = response.getWriter();
       
       Map<String,Object> data = JSONUtil.jsonToMap(request.getParameter("data"));
       Map<String,Object> operationInfo; // contiene mensajes de los sucesos de la operación
User user = UserUtil.getUser4login((String)data.get("username")); // obtiene el usuario si existe

if(user != null)
{
operationInfo = new HashMap<>();
// si el password ingresado coincide con el password del usuario hasheado -> Login correcto
if(BCrypt.checkpw((String)data.get("password"), user.getPassword()))
{
operationInfo.put("message", "Login correcto");
}
else
{
response.setStatus(HttpServletResponse.SC_BAD_REQUEST);
operationInfo.put("message", "Contreña incorrecta");
}
writer.print(new JSONObject(operationInfo));
}
else
{
response.setStatus(HttpServletResponse.SC_BAD_REQUEST);
operationInfo = new HashMap<>();
operationInfo.put("message", "Usuario no encontrado");

writer.print(new JSONObject(operationInfo));
}
writer.flush();

}

}
  
  Lo primero que hacemos es establecer una cabecera para el tipo de respuesta. Como vamos a devolver un archivo JSON, establecemos el content type como "application/json". Luego obtenemos el objeto PrintWriter para mostrar datos en pantalla.
  
  Aquí viene algo interesante. Hacemos una llamada al método estático jsonToMap de la clase JSONUtil que hemos creado y le pasamos lo siguiente:
  
  Código (java) [Seleccionar] Expandir
  
Request.getAttribute("data")
  
  ¿Qué significa esto? Bien, si recuerdas, en el archivo call_servlet_ajax, en la data a enviar enviamos un JSON que tenía la llave "data" y el valor "dataToSend" que era un String con forma de JSON.
  
  Bien, request.getAtributte("data"), obtiene el valor de la llave "data" que le hemos enviado mediante AJAX. Entonces, ¿qué hace el método jsonToMap con éste JSON en formato String que hemos obtenido?
  
  Lo convierte a JSON con:
  
  
  Código (java) [Seleccionar] Expandir
  jsonObj = new JSONObject(stringifyJSON);

  E itera el JSON para guardar las llaves y los valores en un Map (array asociativo) y lo devuelve. Entonces, el objeto Map data del Servlet, recibe el objeto Map que retorna el método jsonToMap.
  
  Crea un objeto Map para guardar los mensajes dependiendo de los sucesos y enviarlos de vuelta por AJAX. Crea un objeto User y utiliza el método estático getUser4login de UserUtil, pasándole el nombre de usuario para que el método consulte si existe y devuelva el Usuario encontrado o null si no lo encuetra.
  
  Evaluamos, si el usuario ha sido encontrado, comparamos las contraseñas. Para esto, hacemos uso del método estático checkpw de la librería jBCrypt para verificar la contraseña enviada por el formulario con la contraseña que está hasheada en la BBDD.
  
  Si la contraseña coincide, guardamos en el mapa el mensaje "Login correcto". Si la contraseña no coincide, guardamos en el mapa el mensaje "Contraseña incorrecta".
  
  Finalmente devolvemos el mapa convertido en JSON pasándole el mapa al constructor de la clase JSONObject. Una vez devuelto el objeto JSON al archivo javascript, podremos mostrar los mensajes que le hemos enviado desde el Servlet.
  
  En el método success, simplemente se le asigna al elemento p hijo de #error-message el texto enviado desde el Servlet. Además de un cambio de clases CSS para mostrar el mensaje con un efecto de "fade", en el método fail, exactamente lo mismo.
  
  
  
  RESULTADO FINAL
  
  
  
  Logueo exitoso:
  
  
  
  
  Logueo con error de validación:
  
  
  
  
  

[Active Record]

Supongamos que tengo una interface:

Código (php) [Seleccionar] Expandir

<?php

interface ActiveRecord
{
public function save();
public function update();
public function delete();
public function find($id);
public function all();
}

Y una clase que lo implementa:

Código (php) [Seleccionar] Expandir

<?php

abstract class ActiveRecordImpl implements ActiveRecord
{

public function save()
{

}

public function update()
{

}

public function delete()
{

}

public function find($id)
{

}

public function all()
{

}

}


Además dos clases: Customer y User (con sus __get y __set) que heredan de Active Record.

Bien, supongamos que el método save() de ActiveRecord necesita guardar un objeto en la BD de la siguiente manera:

Código (php-brief) [Seleccionar] Expandir

<?php

public function save()
{
$caller = REFERENCIA_AL_OBJETO_LLAMANTE;
$callerClass = get_class($caller); // 'Customer' o 'User'

// obtiene el servicio dinámicamente, de acuerdo al objeto llamante
$service = ServiceFactory::create($callerClass);

// le envía el objeto llamante al servicio Customer para que
// lo guarde en la BD
$service->save($caller);
}

El método save() obtiene una referencia al método que lo llamó (que puede ser un objeto tipo Customer o User), y obtiene la clase del objeto llamante para poder crear su servicio respectivo. Posteriormente, el servicio guarda el objeto por medio del método save()

La clase ServiceFactory solo crea y devuelve un servicio para el tipo de clase indicado:

Código (php) [Seleccionar] Expandir

<?php

public static function create($class)
{
switch ($class) {
case 'Customer':
return new CustomerService();

case 'User':
return new UserService();
}
}


Y los servicios de 'Customer' y 'User' hacen uso de sus DAOs respectivos:

Código (php) [Seleccionar] Expandir

<?php

class CustomerService
{
public function save(Customer $customer)
{
new CustomerDAO()->save($customer);
}
}

Código (php) [Seleccionar] Expandir

<?php

class UserService
{
public function create(User $user)
{
new UserDAO()->save($user);
}
}

Ahora, para guardar un objeto 'Customer' y 'User' se haría lo siguiente:

Código (php) [Seleccionar] Expandir

<?php

$customer = new Customer();
$customer->username = $username;
$customer->email = $email;
$customer->password = $password;
$customer->dni = $dni;
$customer->address = $address;

$user = new User();
$user->username = $username;
$user->email = $email;
$user->password = $password;

¿Es ésto posible? Si es es así, ¿cómo podría obtener la referencia del objeto llamante?