elhacker.net cabecera Bienvenido(a), Visitante. Por favor Ingresar o Registrarse
¿Perdiste tu email de activación?.

 

 


Tema destacado: (TUTORIAL) Aprende a emular Sentinel Dongle By Yapis


  Mostrar Temas
Páginas: [1] 2 3
1  Programación / Java / Timer & TimerTask en: 29 Julio 2015, 22:28 pm

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
  1. public class Display {
  2.  
  3.    public void printTime(int hour, int minute, int second) {
  4.        String fullHour = "";
  5.  
  6.        fullHour += (hour > 9) ? ":" + hour : "0" + hour;
  7.        fullHour += (minute > 9) ? ":" + minute : ":0" + minute;
  8.        fullHour += (second > 9) ? ":" + second : ":0" + second;
  9.  
  10.        System.out.println(fullHour);
  11.    }
  12. }

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
  1. import java.util.Timer;
  2. import java.util.TimerTask;
  3.  
  4. public class Timeout {
  5.  
  6.    private int hour = 0;
  7.    private int minute = 0;
  8.    private int second = 11;
  9.    private Timer timer;
  10.    private boolean isTimerRunning;
  11.    private Display display;
  12.  
  13.    public Timeout() {
  14.        timer = new Timer();
  15.        display = new Display();
  16.    }
  17.  
  18.    TimerTask task = new TimerTask() {
  19.        @Override
  20.        public void run() {
  21.            isTimerRunning = true;
  22.            if(second > 0) {
  23.                second--;
  24.            } else {
  25.                second = 59;
  26.                if(minute > 0) minute--;
  27.                else {
  28.                    minute = 59;
  29.                    if(hour > 0) hour--;
  30.                    // si segundo = 0, minuto = 0 y hora = 0,
  31.                    // cancelamos el timer
  32.                    else {
  33.                        isTimerRunning = false;
  34.                        timer.cancel();
  35.                        timer.purge();
  36.                    }
  37.                }
  38.            }
  39.            if(isTimerRunning)
  40.                display.printTime(hour, minute, second);
  41.        }
  42.    }; // fin timertask
  43.  
  44.    public void start(int timeout, int interval) {
  45.        timer.schedule(task, timeout, interval);
  46.    }
  47.  
  48. } // 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
  1. public class TimerTest {
  2.  
  3.    public static void main(String[] args) {
  4.        Timeout timeout = new Timeout();
  5.        timeout.start(0, 1000);
  6.    }
  7. }

En la clase principal decimos que el timer tendrá un delay de 0s y un intervalo de 1s. Si compilamos y corremos:

Código
  1. javac Display.java
  2. javac Timeout.java
  3. javac TimerTest.java
  4.  
  5. java TimerTest

Obtendremos lo siguiente:


¿Posibilidades? La que puedas imaginar, así que piensa como sacarle provecho en tu próximo proyecto.
2  Programación / Java / CDI 1.1 - Context and Dependecy Injection en: 15 Julio 2015, 03:56 am
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
  1. public class BankLoan {
  2.    @Inject
  3.    private AccountChecker accountChecker;
  4.    private Date dateOfLoan;
  5.  
  6.    @PostConstruct
  7.    private void initializeDate() {
  8.        dateOfLoan = new Date();
  9.    }
  10. }

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
  1. public class CDStore {
  2.    private CreditCard creditCard;
  3.  
  4.    public CDStore() {
  5.        creditCard = new Visa();
  6.    }
  7.    public void buyItems() {
  8.        // pagar con la tarjeta
  9.  creditCard.pay();
  10.    }
  11. }

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
  1. public class CDStore {
  2.    private CreditCard creditCard;
  3.  
  4.    public CDStore(CreditCard creditCard) {
  5.        this.creditCard = creditCard;
  6.    }
  7.    ...
  8. }

En otra clase:

Código
  1. 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
  1. public class CDStore {
  2.    @Inject
  3.    private CreditCard creditCard;
  4.  
  5.    public void buyItems() {
  6.        creditCard.pay();
  7.    }
  8.    ...
  9. }

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
  1. public class Visa implements CreditCard {
  2.    @Override
  3.    public void pay() {
  4.         // logica de negocio
  5.    }
  6. }

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
  1. @Inject
  2. private CreditCard creditCard;

   Nota que no es necesario especificar setter para la propiedad.
  • Por constructor:
Código
  1. @Inject
  2.         private CDStore (CreditCard creditCard) {
  3.             this.creditCard = creditCard;
  4.        }

   La regla aquí es que la inyección por constructor se puede realizar solo una vez (por    clase).

  • Por setter:
Código
  1. @Inject
  2.        public void setCreditCard(CreditCard creditCard) {
  3.            this.creditCard = creditCard;
  4.        }


É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
  1. @Inject
  2. private CreditCard creditCard;

Es igual que:

Código
  1. @Inject @Default
  2. 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
  1. @Qualifier
  2. @Retention(RUNTIME)
  3. @Target({FIELD, TYPE, PARAMETER, METHOD})
  4. public @interface MasterCardPay {}

Implementación MasterCard:

Código
  1. @MasterCardPay
  2. public class MasterCard implements CreditCard {
  3.    private Logger logger = Logger.getLogger(MasterCard.class.getName());
  4.  
  5.    @Override
  6.    public void pay() {
  7.        logger.log(Level.INFO, "Pagando con MasterCard");
  8.    }
  9. }

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
  1. public class CDStoreWithQualifier {
  2.    @Inject @MasterCardPay
  3.    private CreditCard masterCard;
  4.  
  5.    public void buyItems() {
  6.        masterCard.pay();
  7.    }
  8. }

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
  1. @Inject @Visa @Gold
  2. 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
  1. @Retention(RUNTIME)
  2. @Target({FIELD, TYPE, PARAMETER, METHOD})
  3. public @interface CDSerialPrefix { }

Código
  1. @Retention(RUNTIME)
  2. @Target({FIELD, TYPE, PARAMETER, METHOD})
  3. public @interface RandomNumber { }

Ahora, veamos como producimos beans para inyectar de tipo String e int:

Código
  1. public class CDSerialProducer {
  2.    @Produces @CDSerialPrefix
  3.    private final String prefix = "T9-SK534";
  4.  
  5.    @Produces @RandomNumber
  6.    public int generateNumber() {
  7.        return new Random().nextInt(10000);
  8.    }
  9. }

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
  1. public class CDService {
  2.    @Inject @CDSerialPrefix
  3.    private String prefix;
  4.    @Inject @RandomNumber
  5.    private int number;
  6.    private Logger logger = Logger.getLogger(getClass().getName());
  7.  
  8.    public void createCD() {
  9.        logger.log(Level.INFO, "Creando CD con serial: {0}", (prefix + number));
  10.    }
  11. }

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
  1. 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
  1. public class LoggerProducer {
  2.    @Produces
  3.    private Logger createLogger(InyectionPoint ip) {
  4.        return Logger.getLogger(ip.getMember().getDeclaringClass().getName());
  5.    }
  6. }

Perfecto. Ahora tan solo debemos inyectar al logger de ésta manera:

Código
  1. @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
  1. public class DerbyJdbcProducer {
  2.    private final static String DRIVER = "org.apache.derby.jdbc.EmbeddedDriver";
  3.    private final static String URL = "jdbc:derby://localhost:1527/CDI";
  4.    private final static String USER = "duke";
  5.    private final static String PASS = "1234";
  6.    @Inject
  7.    private Logger logger;
  8.  
  9.    @Produces
  10.    public Connection createConnection() {
  11.        Connection con = null;
  12.        try {
  13.            Class.forName(DRIVER).newInstance();
  14.            con = DriverManager.getConnection(URL, USER, PASS);
  15.            logger.log(Level.INFO, "Creando conexión JDBC con Derby");
  16.                ClassNotFoundException | SQLException e) {
  17.            e.printStackTrace();
  18.        }
  19.        return con;
  20.    }
  21.    public void closeConnection(@Disposes Connection con) {
  22.        try {
  23.            con.close();
  24.            logger.log(Level.INFO, "Cerrando conexión JDBC con Derby");
  25.        } catch (SQLException e) {
  26.            e.printStackTrace();
  27.        }
  28.    }
  29. }

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.

Citar
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
  1. @Named
  2. @ConversationScoped
  3. public class UserRegistrationWizard implements Serializable {
  4.    @Inject
  5.    private Conversation conversation;
  6.    @Inject
  7.    private User user;
  8.    @Inject
  9.    private transient Logger logger;
  10.  
  11.    @PostConstruct
  12.    public void init() {
  13.        conversation.begin();
  14.    }
  15.    public User getUser() {
  16.        return user;
  17.    }
  18.    public void register() {
  19.        conversation.end();
  20.        logger.log(Level.INFO, "Usuario registrado:");
  21.        logger.log(Level.INFO, "Email: {0}", user.getEmail());
  22.        logger.log(Level.INFO, "Password: {0}", user.getPassword());
  23.        logger.log(Level.INFO, "Fecha Nacimiento: {0}", user.getBirthDate());
  24.    }
  25. }

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
  1. <h3>Inicio de registro</h3>
  2.        <h:form>
  3.            <h:outputLabel for="email" value="Email:"/>
  4.            <h:inputText id="email" value="#{userRegistrationWizard.user.email}"/>
  5.            <h:commandButton value="Siguiente" action="step2"/>
  6.        </h:form>

step2.xhtml

Código
  1. <h3>Paso 2</h3>
  2.        <h:form>
  3.            <h:outputLabel for="password" value="Contraseña"/>
  4.            <h:inputSecret id="password" value="#{userRegistrationWizard.user.password}"/>
  5.            <h:commandButton value="Siguiente" action="end"/>
  6.        </h:form>

end.xhtml

Código
  1. <h3>Paso 3</h3>
  2.        <h:form>
  3.            <h:outputLabel for="birthDate" value="F. Nacimiento:"/>
  4.            <h:inputText id="birthDate" value="#{userRegistrationWizard.user.birthDate}">
  5.                <f:convertDateTime pattern="dd-MM-yyyy"/>
  6.            </h:inputText>
  7.            <h:commandButton value="Registrar" action="#{userRegistrationWizard.register()}">
  8.                <f:ajax execute="@form" />
  9.            </h:commandButton>
  10.        </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
  1. @AroundInvoke
  2. 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
  1. @Interceptors(MisInterceptores.class)
  2. public class MiClase { ... }

O en algún método:

Código
  1. @Interceptors(MisInterceptores.class)
  2. 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
  1. public class LoginInterceptor {
  2.    private @Inject Logger logger;
  3.  
  4.    @AroundConstruct
  5.    private Object init(InvocationContext ic) throws Exception {
  6.        logger.log(Level.INFO, "--- ConstructInterceptor ---");
  7.        logger.log(Level.INFO, "Entrando al constructor");
  8.        try {
  9.            return ic.proceed();
  10.        } finally {
  11.            logger.log(Level.INFO, "Saliendo del constructor");
  12.        }
  13.    }
  14.    @AroundInvoke
  15.    private Object interceptMethod(InvocationContext ic) throws Exception {
  16.        logger.entering(ic.getTarget().toString(), ic.getMethod().getName());
  17.        try {
  18.            logger.log(Level.INFO, "método interceptado");
  19.            return ic.proceed();
  20.        } finally {
  21.            logger.exiting(ic.getTarget().toString(), ic.getMethod().getName());
  22.        }
  23.    }  
  24. }

Y nuestra clase que se verá afectada por nuestro inteceptor:

Código
  1. @Interceptors(LoginInterceptor.class)
  2. public class LoginService {
  3.    private @Inject Logger logger;
  4.  
  5.    public void login() {
  6.        logger.log(Level.INFO, "Haciendo login");
  7.    }
  8. }

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.

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

Código
  1. @Interceptors(LoginInterceptor.class, AccountcheckerInterceptor.class)
  2. 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
  1. @InterceptorBinding
  2. @Retention(RUNTIME)
  3. @Target({METHOD, TYPE})
  4. 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
  1. @Interceptor
  2. @Loggable
  3. 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
  1. public class LoginServiceBinding {
  2.    @Loggable
  3.    public void Login() {
  4.        ...
  5.    }
  6. }

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
  1. <beans xmlns="http://xmlns.jcp.org/xml/ns/javaee"
  2.       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  3.       xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
  4.       http://xmlns.jcp.org/xml/ns/javaee/beans_1_1.xsd"
  5.       bean-discovery-mode="all">
  6.    <interceptors>
  7.        <class>com.acme.interceptors.binding.LoginInterceptorBinding</class>
  8.    </interceptors>
  9. </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
  1. @Interceptor
  2. @CdDisponibility
  3. @Priority(200)
  4. public class CdDisponibilityInterceptor {
  5.    @Inject
  6.    private Logger logger;
  7.  
  8.    @AroundInvoke
  9.    public Object checkCdDisponibility(InvocationContext ic) throws Exception {
  10.        try {
  11.            logger.log(Level.INFO, "Ejecuando método interceptor checkCdDisponibility");
  12.            return ic.proceed();
  13.        } finally {
  14.            logger.log(Level.INFO, "Terminando ejecución método interceptor checkCdDisponibility");
  15.        }
  16.    }
  17. }

Código
  1. @Interceptor
  2. @DvdDisponibility
  3. @Priority(300)
  4. public class DvdDisponibilityInterceptor {
  5.    @Inject
  6.    private Logger logger;
  7.  
  8.    @AroundInvoke
  9.    public Object checkDvdDisponibility(InvocationContext ic) throws Exception {
  10.        try {
  11.            logger.log(Level.INFO, "Ejecutando método interceptor checkDvdDisponibility");
  12.            return ic.proceed();
  13.        } finally {
  14.            logger.log(Level.INFO, "Terminando ejecución del método interceptor checkDvdDisponibility");
  15.        }
  16.    }
  17. }

Ahora, nuestra clase interceptada:

Código
  1. @CdDisponibility @DvdDisponibility
  2. public class SellService {
  3.    public void checkDisponibility() {
  4.        ...
  5.    }
  6. }

Si ejecutamos, veremos la siguiente salida:

Código:
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
  1. public interface Membership {
  2.    public int freeCDs();
  3. }

Implementación BasicMembership

Código
  1. @Basic
  2. public class BasicMembership implements Membership {
  3.    @Inject
  4.    private Logger logger;
  5.  
  6.    @Override
  7.    public int freeCDs() {
  8.        logger.log(Level.INFO, "[+] Clase BasicMembership");
  9.        logger.log(Level.INFO, "Gratis 15 CDs");
  10.        return 15;
  11.    }
  12. }

@Basic es un calificador, que como ya sabemos sigue ésta anatomía:

Código
  1. @Qualifier
  2. @Retention(RUNTIME)
  3. @Target({FIELD, TYPE, METHOD, PARAMETER})
  4. public @interface Basic { }

Ahora, veamos nuestro decorador:

Decorador MembershipGiftDecorator

Código
  1. @Decorator
  2. public class MembershipGiftDecorator implements Membership {
  3.    @Inject @Delegate @Basic
  4.    private Membership membership;
  5.    @Inject
  6.    private Logger logger;
  7.  
  8.    public int orderGift() {
  9.        logger.log(Level.INFO, "[+] Clase decoradora para Membership");
  10.        logger.log(Level.INFO, "Regalo momentáneo de 25 CDs");
  11.        return membership.freeCDs() + 25;
  12.    }
  13.    @Override
  14.    public int freeCDs() {
  15.        return orderGift();
  16.    }
  17. }

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
  1. @Named
  2. public class MembershipBean {
  3.    @Inject @Basic
  4.    private Membership gift;
  5.  
  6.    public void orderGift() {
  7.        gift.freeCDs();
  8.    }
  9. }

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:
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
  1. <decorators>
  2.        <class>com.acme.decorator.MembershipGiftDecorator</class>
  3. </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
  1. @Named("cdShopCart")
  2. @RequestScoped
  3. public class CDShopCart {
  4.    @Inject
  5.    private Event<CD> cdAddedEvent;
  6.  
  7.    public void addItem2cart() {
  8.        List<String> songs = new ArrayList<>();
  9.        Collections.addAll(songs,
  10.                "The day that never comes",
  11.                "Enter Sandman",
  12.                "The fourth horseman",
  13.                "Whiskey in the jar");
  14.        CD cd = new CD("Metallica", songs);
  15.        cdAddedEvent.fire(cd);
  16.    }
  17. }

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
  1. @SessionScoped
  2. public class Cart implements Serializable {
  3.    @Inject
  4.    private transient Logger logger;
  5.    private List<CD> items;
  6.  
  7.    @PostConstruct
  8.    public void init() {
  9.        items = new ArrayList<>();
  10.    }
  11.  
  12.    public void addItem(@Observes CD cd) {
  13.        logger.log(Level.INFO, "Nuevo CD añadido al carro");
  14.        logger.log(Level.INFO, "Autor: {0}", cd.getAuthor());
  15.        logger.log(Level.INFO, "Canciones:");
  16.        for(String song : cd.getSongs()) {
  17.            logger.log(Level.INFO, song);
  18.        }
  19.    }
  20. }

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
  1. <h:form>
  2.            <h:commandButton value="Agregar CD al carro" actionListener="#{cdShopCart.addItem2cart()}">
  3.                <f:ajax execute="@form"/>
  4.            </h:commandButton>
  5.        </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:
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
  1. @Named("cdShopCart")
  2. @SessionScoped
  3. public class CDShopCart implements Serializable {
  4.    @Inject @Added
  5.    private Event<CD> cdAddedEvent;
  6.    @Inject @Removed
  7.    private Event<CD> cdRemovedEvent;
  8.    @Inject
  9.    private CD cd;
  10.  
  11.    public void addItem2cart() {
  12.        List<String> songs = new ArrayList<>();
  13.        Collections.addAll(songs,
  14.                "The day that never comes",
  15.                "Enter Sandman",
  16.                "The fourth horseman",
  17.                "Whiskey in the jar");
  18.        cd.setAuthor("Metallica");
  19.        cd.setSongs(songs);
  20.        cdAddedEvent.fire(cd);
  21.    }
  22.    public void removeItemFromCart() {
  23.        cdRemovedEvent.fire(cd);
  24.    }
  25. }

Los métodos observadores del carro, se verán así:

Código
  1. public void addItem(@Observes @Added CD cd) {
  2.        logger.log(Level.INFO, "Nuevo CD añadido al carro");
  3.        logger.log(Level.INFO, "Autor: {0}", cd.getAuthor());
  4.        logger.log(Level.INFO, "Canciones:");
  5.        for(String song : cd.getSongs()) {
  6.            logger.log(Level.INFO, song);
  7.        }
  8.    }
  9.    public void removeItem(@Observes @Removed CD cd) {
  10.        logger.log(Level.INFO, "CD Removido");
  11.        logger.log(Level.INFO, "Autor: {0}", cd.getAuthor());
  12.    }

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
  1. <h:form>
  2.            <h:commandButton value="Agregar CD al carro" action="#{cdShopCart.addItem2cart()}">
  3.                <f:ajax execute="@form"/>
  4.            </h:commandButton>
  5.            <h:commandButton value="Eliminar CD del carro" action="#{cdShopCart.removeItemFromCart()}">
  6.                <f:ajax execute="@form"/>
  7.            </h:commandButton>
  8.        </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.
3  Programación / Java / Subir archivos con Servlet en: 6 Julio 2015, 00:20 am
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
  1. <h1>Subir archivos</h1>
  2.    <form method="post" action="upload" enctype="multipart/form-data">
  3.    <fieldset>
  4.     <legend>Formulario de subida</legend>
  5.     <input type="file" name="files" id="files" multiple/>
  6.        <button type="submit">Subir</button>
  7.    </fieldset>
  8. </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
  1. @WebServlet(name = "UploadServlet", urlPatterns = {"/upload"})
  2. @MultipartConfig(location="D:/uploads")
  3. public class UploadServlet extends HttpServlet {
  4.    private static final long serialVersionUID = 1L;
  5.  
  6.    protected void processRequest(HttpServletRequest request, HttpServletResponse response)
  7.            throws ServletException, IOException {
  8.        response.setContentType("text/html;charset=UTF-8");
  9.        Collection<Part> parts = request.getParts();
  10.        for(Part part : parts) {
  11.         part.write(getFileName(part));
  12.        }
  13.    }
  14.  
  15.    @Override
  16.    protected void doGet(HttpServletRequest request, HttpServletResponse response)
  17.            throws ServletException, IOException {
  18.        processRequest(request, response);
  19.    }
  20.  
  21.    @Override
  22.    protected void doPost(HttpServletRequest request, HttpServletResponse response)
  23.            throws ServletException, IOException {
  24.        processRequest(request, response);
  25.    }
  26.  
  27.    public String getFileName(Part part) {
  28.        String contentHeader = part.getHeader("content-disposition");
  29.        String[] subHeaders = contentHeader.split(";");
  30.        for(String current : subHeaders) {
  31.            if(current.trim().startsWith("filename")) {
  32.             int pos = current.indexOf('=');
  33.                String fileName = current.substring(pos+1);
  34.                return fileName.replace("\"", "");
  35.            }
  36.        }
  37.        return null;
  38.    }
  39. }

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
  1. ------WebKitFormBoundaryKZUc66kZeBth3nDc
  2. Content-Disposition: form-data; name="files"; filename="jsf-scopes.png"
  3. Content-Type: image/png
  4.  
  5.  
  6. ------WebKitFormBoundaryKZUc66kZeBth3nDc
  7. Content-Disposition: form-data; name="files"; filename="navbar.png"
  8. 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
  1. public String getFileName(Part part) {
  2.        String contentHeader = part.getHeader("content-disposition");
  3.        String[] subHeaders = contentHeader.split(";");
  4.        for(String current : subHeaders) {
  5.            if(current.trim().startsWith("filename")) {
  6.             int pos = current.indexOf('=');
  7.                String fileName = current.substring(pos+1);
  8.                return fileName.replace("\"", "");
  9.            }
  10.        }
  11.        return null;
  12.    }

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
  1. part.write(getFileName(part));

Por último, verificamos si se han subido  los archivos:



Eso es todo. ¿Quién dijo que Java es difícil? :P
4  Programación / Desarrollo Web / [CSS3] Login + preloader en: 25 Junio 2015, 00:37 am
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)

Citar
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
  1. <!DOCTYPE html>
  2. <html lang="es">
  3. <meta charset="UTF-8">
  4. <link rel="stylesheet" href="css/vendor/normalize.css"/>
  5. <link rel="stylesheet" href="//maxcdn.bootstrapcdn.com/font-awesome/4.3.0/css/font-awesome.min.css"/>
  6. <link rel="stylesheet" href="css/main.css"/>
  7. <title>Login</title>
  8. </head>
  9. <section class="main">
  10. <form id="loginFrm" class="form">
  11. <figure class="tooltip"></figure>
  12. <section class="form-head">
  13. <span>Login</span>
  14. <figure class="logo"></figure>
  15. <section class="form-body">
  16. <div class="group">
  17. <label for="user">Email:</label>
  18. <input type="text" id="user" class="txt">
  19. </div>
  20. <div class="group">
  21. <label for="pass">Password:</label>
  22. <input type="password" id="pass" class="txt">
  23. </div>
  24. <div class="group flex-end">
  25. <button type="submit" id="login" class="btn btn-radical">login</button>
  26. </div>
  27. </form>
  28. 'use strict';
  29. window.addEventListener('load', function() {
  30. let main = document.querySelector('.main');
  31. main.classList.add('visible');
  32. });
  33. </script>
  34. <script src="js/auth.js"></script>
  35. </body>
  36. </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
  1. html {
  2. box-sizing: border-box;
  3. }
  4. *, *:before, *:after {
  5. box-sizing: inherit;
  6. }

Luego, aplicamos estilos al container general, es decir, main:

Código
  1. .main {
  2. align-items: center;
  3. background: rgba(136,211,124,1);
  4. background: linear-gradient(to bottom, rgba(136,211,124,1) 0%,
  5. rgba(136,211,124,1) 50%,
  6. rgba(190,144,212,1) 51%,
  7. rgba(190,144,212,1) 71%,
  8. rgba(190,144,212,1) 100%);
  9. background-repeat: repeat;
  10. display: flex;
  11. height: 100vh;
  12. justify-content: center;
  13. opacity: 0;
  14. transition: all .2s linear;
  15. visibility: hidden;
  16. }
  17. .main.visible {
  18. opacity: 1;
  19. visibility: visible;
  20. }

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
  1. .form {
  2. background-color: #f7f7f7;
  3. border: none;
  4. border-radius: 2px;
  5. box-shadow: 0 2px 5px rgba(0,0,0,.25),
  6. 0 -1px 5px rgba(0,0,0,.1);
  7. position: relative;
  8. width: 350px;
  9. }

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
  1. .form-head {
  2. align-items: center;
  3. border-radius: 2px 2px 0 0;
  4. border-bottom: 2px solid #9B59B6;
  5. display: flex;
  6. height: 45px;
  7. }
  8. .form-head > span {
  9. color: #555;
  10. font-family: 'segoe ui';
  11. font-size: 17pt;
  12. font-weight: lighter;
  13. margin-left: 12px;
  14. }

La cabecera del formulario no tiene nada que explicar. Vayamos con el pin:

Código
  1. .form-head .logo {
  2. background-position: center;
  3. background-repeat: no-repeat;
  4. background-image: url('http://urbita.com/img/default/default_user_256.png');
  5. background-size: cover;
  6. border-radius: 100%;
  7. box-shadow: 0px 2px 5px rgba(0,0,0,.25);
  8. height: 85px;
  9. left: calc(50% - 38.5px);
  10. margin: 0px;
  11. position: absolute;
  12. top: calc(0% - 38.5px);
  13. width: 85px;
  14. }

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
  1. @keyframes spin {
  2. from { transform: rotate(0deg); }
  3. to { transform: rotate(1800deg); }
  4. }

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
  1. .form-head .logo.auth {
  2. animation-name: spin;
  3. animation-duration: 3000ms;
  4. animation-iteration-count: 1;
  5. animation-timing-function: linear;
  6. animation-play-state: running;
  7. animation-fill-mode: forwards;
  8. animation-delay: 0s;
  9. }

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
  1. .form-body {
  2. padding: 40px 25px 10px 25px;
  3. }
  4. .group {
  5. align-items: center;
  6. display: flex;
  7. margin-bottom: 10px;
  8. }
  9. .group > label {
  10. color: #777;
  11. display: block;
  12. flex-grow: 1;
  13. font-family: 'segoe ui';
  14. }

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
  1. .flex-end {
  2. justify-content: flex-end;
  3. }
  4. .flex-abs-center {
  5. align-items: center;
  6. justify-content: center;
  7. }

Ahora vayamos con los textboxes:

Código
  1. .txt {
  2. border: 1px solid #ddd;
  3. border-radius: 2px;
  4. color: #777;
  5. font-family: 'segoe ui';
  6. font-size: .9rem;
  7. outline: none;
  8. padding: .35rem .5rem;
  9. transition: all .2s ease;
  10. }
  11. .txt.invalid {
  12. border-color: rgba(231,76,60,.7);
  13. }
  14. .txt:hover {
  15. border-color: #ccc;
  16. }
  17. .txt:focus {
  18. border-color: #bbb;
  19. }
  20.  

Nada del otro mundo. La clase invalid solo pintará el borde del textbox de rojo. Ahora los botones:

Código
  1. .btn {
  2. border: none;
  3. border-radius: 2px;
  4. box-shadow: 0 2px 5px rgba(0,0,0,.2);
  5. font-family: 'segoe ui';
  6. font-size: .9rem;
  7. outline: none;
  8. padding: .45rem 1.25rem;
  9. text-transform: uppercase;
  10. transition: all .3s ease;
  11. }
  12. .btn-radical {
  13. background-color: #F62459;
  14. color: rgba(255,255,255,.9);
  15. margin-top: 15px;
  16. }
  17. .btn-radical:hover {
  18. background-color: #DC1F4E;
  19. }

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
  1. .form .tooltip {
  2. background-color: rgba(0,0,0,.5);
  3. border-radius: 5px;
  4. box-shadow: 0px 2px 5px rgba(0,0,0,.25);
  5. color: rgba(255,255,255,.8);
  6. font-family: 'segoe ui';
  7. font-size: .9rem;
  8. height: 100px;
  9. left: calc(100% - 35px);
  10. margin: 0;
  11. padding: .7rem .6rem;
  12. opacity: 0;
  13. position: absolute;
  14. text-align: center;
  15. top: -140%;
  16. transition: all .4s ease-in;
  17. visibility: hidden;
  18. width: 200px;
  19. }

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
  1. .form .tooltip:before {
  2. border-color: rgba(0,0,0,.5) transparent;
  3. border-style: solid;
  4. border-width: 10px 10px 0px 10px;
  5. content: "";
  6. left: 10px;
  7. position: absolute;
  8. bottom: -10px;
  9. }[/coder]
  10.  
  11. Por último, para hacerlo visible, aplicaremos una clase:
  12.  
  13. [code=css]
  14. .form .tooltip.visible {
  15. opacity: 1;
  16. top: -50%;
  17. visibility: visible;
  18. }

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
  1. 'use strict';
  2. document.addEventListener('DOMContentLoaded', function() {
  3. let loginFrm = document.querySelector('#loginFrm');
  4.  
  5. loginFrm.addEventListener('submit', function(e) {
  6. e.preventDefault();
  7.  
  8. const ANIMATION_TIMEOUT = 3000; // duration of logo animation
  9. let logo = document.querySelector('.logo');
  10. let user = document.querySelector('#user').value.toLowerCase();
  11. let pass = document.querySelector('#pass').value;
  12.  
  13. // if logo already is animated, the info is already processing
  14. if(logo.classList.contains('auth')) {
  15. return false;
  16. }
  17.  
  18. logo.classList.add('auth'); // start animation
  19.  
  20. // check credentials
  21. if(user == 'john.doe@gmail.com' && pass == 'abc123') {
  22. window.setTimeout(function() {
  23. sessionStorage.setItem('full_access', false);
  24. window.location.href = 'views/home.html';
  25. }, ANIMATION_TIMEOUT);
  26. } else {
  27. window.setTimeout(function() {
  28. logo.classList.remove('auth'); // remove animation of logo
  29. showTooltip();
  30. }, ANIMATION_TIMEOUT);
  31. }
  32. });
  33.  
  34. // show and hide tooltip
  35. function showTooltip() {
  36. let tooltip = loginFrm.querySelector('.tooltip');
  37. tooltip.textContent = 'El email o contraseña ingresados no son correctos. Verifique e inténtelo nuevamente.';
  38. tooltip.classList.add('visible');
  39. // after 4 seconds, the tooltip disappear
  40. window.setTimeout(function() {
  41. tooltip.classList.remove('visible');
  42. }, 4000);
  43. }
  44. }); // 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
  1. 'use strict';
  2. window.addEventListener('load', function() {
  3. let main = document.querySelector('.main');
  4. main.classList.add('visible');
  5. });



2. HOME


HTML

  • Normalize.css requerido
  • Prefixfree requerido
Código
  1. <!DOCTYPE html>
  2. <html lang="es">
  3. <meta charset="UTF-8">
  4. <link rel="stylesheet" href="../css/vendor/normalize.css"/>
  5. <link rel="stylesheet" href="//maxcdn.bootstrapcdn.com/font-awesome/4.3.0/css/font-awesome.min.css"/>
  6. <link rel="stylesheet" href="../css/home.css"/>
  7. <script src="js/vendor/prefixfree.min.js"></script>
  8. <title>Home page</title>
  9. </head>
  10. <section class="preload"><i class="fa fa-4x fa-circle-o-notch fa-spin"></i></section>
  11. <section class="main">
  12. <nav class="navbar">
  13. <!-- brand -->
  14. <a href="#" class="brand">Oh yeah!<i class="fa fa-2x fa-hand-o-right"></i></a>
  15. <!-- menu -->
  16. <ul class="menu">
  17. <li><a href="#">Messages<i class="fa fa-envelope"></i></a></li>
  18. <li>
  19. <a href="#">John doe<i class="fa fa-caret-down"></i></a>
  20. <ul>
  21. <li><a href="#" id="profile-img">
  22. <img src="http://i.imgur.com/IxWfQy2.jpg"/></a>
  23. </li>
  24. <li><a href="#">Profile<i class="fa fa-user"></i></a></li>
  25. <li><a href="#">Settings<i class="fa fa-cog"></i></a></li>
  26. <li><a href="#" id="logout">Logout<i class="fa fa-sign-out"></i></a></li>
  27. </ul>
  28. </li>
  29. </ul>
  30. </nav>
  31. </header>
  32. <script src="js/homeui.js"></script>
  33. </body>
  34. </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
  1. html { box-sizing: border-box; }
  2. *, *: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
  1. .preload {
  2. align-items: center;
  3. background-color: #F22613;
  4. display: flex;
  5. height: 100vh;
  6. justify-content: center;
  7. left: 0;
  8. opacity: 0;
  9. position: absolute;
  10. top: 0;
  11. transition: all .5s ease;
  12. visibility: hidden;
  13. width: 100%;
  14. z-index: 1;
  15. }
  16. .preload.visible {
  17. opacity: 1;
  18. visibility: visible;
  19. }
  20. .preload i {
  21. color: rgba(255,255,255,.9);
  22. }

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
  1. .main {
  2. opacity: 0;
  3. transition: all .6s ease;
  4. visibility: hidden;
  5. }
  6. .main.visible {
  7. opacity: 1;
  8. visibility: visible;
  9. }

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
  1. header {
  2. background-color: #22A7F0;
  3. color: rgba(255,255,255,.9);
  4. display: block;
  5. }
  6. .navbar {
  7. align-items: center;
  8. color: inherit;
  9. display: flex;
  10. justify-content: space-between;
  11. margin: 0px;
  12. padding: 0 .5rem;
  13. width: 100%;
  14. }

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
  1. .brand {
  2. align-self: stretch;
  3. align-items: center;
  4. color: inherit;
  5. display: flex;
  6. font-family: 'segoe ui';
  7. margin: 0px;
  8. padding: 0 .25rem;
  9. }
  10. .brand > i {
  11. margin-left: .8rem;
  12. }

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
  1. .navbar ul {
  2. display: block;
  3. list-style: none;
  4. margin: 0px;
  5. padding: 0px;
  6. }
  7. .navbar > .menu {
  8. display: block;
  9. }
  10. .menu > li {
  11. display: inline-block;
  12. transition: all .1s ease-in;
  13. }
  14. .menu > li:hover {
  15. background-color: #1C99DD;
  16. }

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
  1. .menu > li > a {
  2. display: block;
  3. padding: 1rem .5rem;
  4. }
  5. .menu > li > a > i {
  6. margin-left: 10px;
  7. }
  8. .menu > li:not(:last-of-type) {
  9. margin: 0 55px 0 0;
  10. }

Veamos ahora, el dropdwon que serán las opciones del usuario.

Código
  1. /* last li (profile dropdown) */
  2. .menu > li:last-of-type {
  3. position: relative;
  4. }
  5. /* dropdown */
  6. .menu > li:last-of-type > ul {
  7. background-color: #22A7F0;
  8. border-radius: .1725rem;
  9. left: -50%;
  10. opcity: 0;
  11. padding: .5rem 0;
  12. position: absolute;
  13. top: 170%;
  14. visibility: hidden;
  15. transition: all .14s ease-in;
  16. }
  17. /* arrow of menu */
  18. .menu > li:last-of-type > ul:after {
  19. border-color: #22A7F0 transparent;
  20. border-style: solid;
  21. border-width: 0 8px 8px 8px;
  22. content: "";
  23. position: absolute;
  24. right: 8px;
  25. top: -7px;
  26. }
  27. .menu > li:last-of-type:hover > ul {
  28. opacity: 1;
  29. top: 130%;
  30. visibility: visible;
  31. }
  32.  

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
  1. /* dropdown list items*/
  2. .menu > li:last-of-type > ul > li, .menu > li:last-of-type > ul a {
  3. display: block;
  4. font-size: .9rem;
  5. transition: transform .1s ease-in;
  6. }
  7. /* dropdown options */
  8. .menu > li:last-of-type > ul a {
  9. padding: .5rem .9rem;
  10. width: 8rem;
  11. }
  12. /* a elements of dropdown options */
  13. .menu > li:last-of-type > ul li:hover {
  14. background-color: #1998DC;
  15. }
  16. /* margin left to dropdown icon */
  17. .menu > li:last-of-type > a > i {
  18. margin-left: .8rem;
  19. }
  20. /* dropdown options icons */
  21. .menu li:last-of-type > ul a > i {
  22. float: right;
  23. margin-top: .3125rem;
  24. }

Por último, la sección donde irá el avatar del usuario:

Código
  1. /* profile image */
  2. #profile-img {
  3. display: flex;
  4. justify-content: center;
  5. margin-bottom: 5px;
  6. pointer-events: none;
  7. width: 100%;
  8. }
  9. #profile-img > img {
  10. background-position: center;
  11. background-size: cover;
  12. border-radius: 50%;
  13. display: block;
  14. height: 5rem;
  15. width: 5rem;
  16. }

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
  1. 'use strict';
  2. window.addEventListener('load', function() {
  3. let full_access = sessionStorage.getItem('full_access');
  4. let preload = document.querySelector('.preload');
  5. let main = document.querySelector('.main');
  6. // full_access is gived when user enter for first time
  7. if(full_access == "false") {
  8. // show preload animation
  9. preload.classList.add('visible');
  10. // animation delay 3s. After that, the main content appear
  11. window.setTimeout(function() {
  12. preload.classList.remove('visible');
  13. main.classList.add('visible');
  14. },3000);
  15. // change the flag. Now, the user has full access
  16. sessionStorage.setItem('full_access', true);
  17. }
  18. // if user has full_access, just show the page
  19. else {
  20. main.classList.add('visible');
  21. }
  22. });
  23. document.addEventListener('DOMContentLoaded', function() {
  24. document.querySelector('#logout').addEventListener('click', function(e) {
  25. e.preventDefault();
  26. // remove user's session
  27. sessionStorage.removeItem('full_access');
  28. // redirect to login
  29. window.location.href = '/PreloadCSS';
  30. });
  31. });

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]
5  Programación / Desarrollo Web / [HTML5] Pizarra virtual en: 19 Abril 2015, 22:24 pm
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.
6  Foros Generales / Foro Libre / Cumbre de las Américas en Panamá en: 11 Abril 2015, 18:27 pm
¿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.
7  Programación / Java / [JavaEE - JavaFx] RESTful con JPA (CRUD) y cliente en JavaFX en: 8 Abril 2015, 18:05 pm

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
  1. <dependency>
  2.    <groupId>org.hibernate</groupId>
  3.    <artifactId>hibernate-core</artifactId>
  4.    <version>4.3.5.Final</version>
  5. </dependency>
  6.  
  7. <dependency>
  8.    <groupId>org.hibernate</groupId>
  9.    <artifactId>hibernate-entitymanager</artifactId>
  10.    <version>4.3.5.Final</version>
  11. </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




Código fuente


Todo el código así como los WAR y JAR están en mi cuenta de Github: REST-FX-CustomersApp.
8  Foros Generales / Sugerencias y dudas sobre el Foro / Evitar temas duplicados en: 7 Abril 2015, 13:36 pm
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.
9  Programación / Desarrollo Web / [CSS] Simple y bonito formulario de ingreso. en: 25 Marzo 2015, 21:28 pm
Les comparto un bonito formulario de ingreso que hice para un tuto de Java EE. Me basé en éste PSD:


HTML:

Código
  1. <!DOCTYPE html>
  2. <html lang="es">
  3. <meta charset="UTF-8"/>
  4. <title>Identfíquese</title>
  5. <link rel="stylesheet" href="http://maxcdn.bootstrapcdn.com/font-awesome/4.3.0/css/font-awesome.min.css"/>
  6. <link rel="stylesheet" href="assets/css/login.css"/>
  7. </head>
  8. <div id="flogin" class="flogin">
  9.        <section class="left-side">
  10.            <section class="head">
  11.                LOGIN
  12.            </section>
  13.            <section class="body">
  14.                <section class="data">
  15.                    <section class="form-group">
  16.                        <span>Usuario:</span>
  17.                        <section class="input-wrapper">
  18.                            <input type="text" id="txt-username" class="txt"/>
  19.                            <i class="fa fa-user"></i>
  20.                        </section>
  21.                    </section>
  22.                    <section class="form-group">
  23.                        <span>Contraseña:</span>
  24.                        <section class="input-wrapper">
  25.                            <input type="password" id="txt-password" class="txt"/>
  26.                            <i class="fa fa-key"></i>
  27.                        </section>
  28.                    </section>
  29.                </section>
  30.                <section class="help">
  31.                    <a href="">¿Olvidaste tu usuario o contraseña?</a>
  32.                </section>
  33.            </section>
  34.        </section>
  35.        <section id="btn-login" class="right-side">
  36.            <i class="fa-4x fa fa-arrow-right"></i>
  37.            <span>IR</span>
  38.        </section>
  39.    </div>
  40.  
  41. </body>
  42. </html>

CSS:

Código
  1. .flogin {
  2.    display: flex;
  3.    justify-content: space-between;
  4.    width: 400px;
  5. }
  6. .flogin > .left-side {
  7.    background-color: #363636;
  8.    /*background: radial-gradient(#555, #363636, #363636);*/
  9.    box-shadow: 0px 0px 20px 20px #2e2e2e inset;
  10.    border: 9px solid #dedede;
  11.    border-right: none;
  12.    border-radius: 20px 0px 0px 20px;
  13.    width: 80%;
  14. }
  15. .flogin  > .right-side {
  16.    align-items: center;
  17.    background-color: #34B5D5;
  18.    border: 9px solid #dedede;
  19.    border-left: none;
  20.    border-radius: 0px 20px 20px 0px;
  21.    display: flex;
  22.    flex-flow: column nowrap;
  23.    justify-content: space-between;
  24.    padding: 1.3rem .2rem;
  25.    width: calc(20% - 2*.2rem - 9px);
  26. }
  27. .flogin > .right-side:hover {
  28.    cursor: pointer;
  29. }
  30.  
  31. /*********************
  32.       LEFT SIDE
  33. *********************/
  34. .left-side > .head {
  35.    border-bottom: 2px dashed #ddd;
  36.    color: #eee;
  37.    font-family: "segoe ui";
  38.    margin-bottom: 20px;
  39.    padding: .75rem 1rem;
  40. }
  41. .left-side > .body {
  42.    padding: .8rem 1.35rem;
  43.    width: calc(100% * 2*1.35rem);
  44. }
  45. .body > .data {
  46.    display: flex;
  47.    justify-content: space-between;
  48. }
  49. .form-group {
  50.    width: 45%;
  51. }
  52. .form-group > span {
  53.    color: #ddd;
  54.    display: block;
  55.    font-family: "segoe ui";
  56.    font-size: 10pt;
  57.    margin-bottom: 7px;
  58. }
  59. .form-group > .input-wrapper {
  60.    align-items: center;
  61.    background-color: white;
  62.    border-radius: 5px;
  63.    box-shadow: 0px 2px 5px 1px rgba(0,0,0,.4) inset,
  64.        0px -1px 2px 1px rgba(0,0,0,.25) inset;
  65.    display: flex;
  66.    justify-content: space-between;
  67. }
  68. .input-wrapper > .txt {
  69.    width: 80%;
  70. }
  71. .input-wrapper > i {
  72.    color: gold;
  73.    width: 20%;
  74. }
  75. .txt {
  76.    background-color: transparent;
  77.    border: none;
  78.    border-radius: 5px;
  79.    padding: .4rem .25rem;
  80.    width: calc(80% - 2*.35rem - 2*1px);
  81. }
  82. .txt:focus {
  83.    outline: none;
  84. }
  85. .help {
  86.    display: flex;
  87.    justify-content: flex-end;
  88. }
  89.  
  90. a {
  91.    color: #ddd;
  92.    display: block;
  93.    font-family: "segoe ui";
  94.    font-size: 10pt;
  95.    font-style: italic;
  96.    margin-top: 20px;
  97.    text-align: right;
  98.    text-decoration: none;
  99. }
  100.  
  101. /*****************
  102.     RIGHT SIDE
  103. *****************/
  104. .right-side > i {
  105.    color: #fff;
  106.    display: block;
  107. }
  108. .right-side > span {
  109.    color: #fff;
  110.    display: block;
  111.    font-family: "segoe ui";
  112.    font-size: 16pt;
  113. }

Resultado:



Saludos.
10  Programación / Java / [Tutorial] Servlets y AJAX en: 25 Marzo 2015, 16:34 pm


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




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:

Citar
C://Program Files/

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

Citar
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:

Páginas: [1] 2 3
WAP2 - Aviso Legal - Powered by SMF 1.1.21 | SMF © 2006-2008, Simple Machines