anchor.diff:  Veamos el porqué de estos valores:
   
   * Name: DisponibilidadBean. Es el nombre de la clase que se genera. Tenemos que elegirlo de manera que explique el caso de uso que soporta. En este caso lo que se muestra al usuario es la disponibilidad de los drones en una fecha. La segunda parte del nombre indica que se trata de un bean gestionado por CDI. En Java EE la clase managed o backing bean representa el Modelo del patrón MVC.
  -* Interfaces: La anotación @Named incluye el bean en el contexto EL de JSF lo que me va a permitir acceder a sus atributos y metodos usando el lenguaje unificado de expresiones EL, en general desde una página facelet o, en ocasiones, desde código java donde no disponga de una referencia al bean. En EL el nombre por defecto para el bean se toma del nombre de la clase en minúscula. En nuestro caso tendremos _disponibilidadBean_.
  +* Interfaces: La anotación @Named incluye el bean en el contexto EL de JSF lo que me va a permitir acceder a sus atributos y métodos usando el lenguaje unificado de expresiones EL, en general desde una página facelet o, en ocasiones, desde código java donde no disponga de una referencia al bean. En EL el nombre por defecto para el bean se toma del nombre de la clase en minúscula. En nuestro caso tendremos _disponibilidadBean_.
   * Scope: @RequestScoped: Define el tiempo de vida y la visibilidad del bean. En este caso el bean está disponible sólo para los objetos que existan en la thread creada para gestionar la request donde se crea el bean. 
   
   NOTE: Una pega de la versión 2.1 de JSF, y al mismo tiempo una buena razón para actualizar en el servidor a la versión 2.2, es que el scope @ViewScoped, muy usado con formularios AJAX y en casos de uso que implican una o dos pantallas, no está integrado con el contexto CDI. Esto deriva en problemas como no poder inyectar beans CDI en un managed bean view scoped.
  
positive.code: . En el explorador los iconos de los elementos del proyecto mostrarán un símbolo amarillo abajo a la derecha.
  . Si pulsamos de nuevo botón derecho sobre el proyecto y la opción _Team_ esta vez aparecerán las opciones correspondientes a las distintas acciones que podemos realizar sobre nuestro repositorio o sobre el repositorio remoto en GitHub.
  
  Hasta el próximo Post!
negative.code: = Desarrollo de una aplicación desde cero: Implementación y depuración de Modelo y Vista.
  La metaweb
  :hp-tags: JSF, JavaServer Faces, MVC, Facelets, managed bean, backing bean, CDI, Depuración, Debugging, Git, GitHub
  :published_at: 2015-07-07
  
  Y llegamos al último post de esta serie. Estamos a pocos pasos de implementar una aplicación completa Java EE que, a pesar de ser muy básica, toca las principales tecnologías del stack. Una aplicación que nos servirá para ganar la confianza necesaria y como base sobre la que ensayar soluciones a cualquier requisito de cliente que podamos imaginar.
  
  En el post anterior conseguimos ya una aplicación funcional, sin embargo la capa de presentación se limitaba a un simple "Hola mundo!". Ahora toca resolver el caso de uso planteado inicialmente. Tendremos que añadir tan solo un par de ficheros: Una clase managed bean y una página Facelets.
  
  Empecemos por la clase. Creamos una carpeta de nombre `vista` dentro de la carpeta _jdrone/src/main/java/com/lametaweb/jdrone/_ . Pulsamos 
  botón derecho sobre la nueva carpeta y _New > Other... > CDI (Context and Dependency Inyection) > Bean_, para crear un bean CDI. Y en la ventana introducimos los valores indicados en la siguiente figura:
  