6.1 ¿Qué son los JavaBeans?

Ya a finales de los 90, el lenguaje Java comenzó a usarse activamente para aplicaciones de servidores grandes, donde el número de clases se mide en decenas y cientos de miles. Fue entonces cuando surgió la idea de estandarizar el aspecto de los objetos de Java.

No se tocó todo el lenguaje Java, para no privarlo de flexibilidad. Bueno, retrocompatibilidad y todo eso. Luego desarrollaron una serie de criterios para los objetos Java de nueva generación y los llamaron Java Beans. Java lleva el nombre de una popular marca de café, por lo que Java Beans se traduce literalmente como "granos de café".

Los criterios más importantes fueron:

  • El acceso a los campos internos de la clase pasa por el getProperty().
  • La escritura de datos en campos de clase pasa por el setProperty(value).
  • La clase debe tener un constructor público sin parámetros .
  • La clase debe ser serializable.
  • La clase debe tener anulados los métodos equals(), hashCode()y toString().

Este enfoque hizo que las aplicaciones fueran menos coherentes. Siempre claro:

  • cómo crear un objeto: hay un constructor público predeterminado;
  • cómo obtener/establecer el valor de la propiedad;
  • cómo transferir/guardar un objeto (usamos serialización);
  • cómo comparar objetos (usando equals() y hashCode());
  • cómo mostrar información sobre el objeto en el registro (use toString).

Ahora es en realidad el estándar de la industria, pero alguna vez fue una nueva tendencia. Parece que ya todo el mundo escribe así, aunque si os acordáis de HttpClient y sus Builders, podéis ver que el nuevo estándar le cuesta a alguien.

Dichos objetos son ampliamente utilizados donde su principal carga semántica es el almacenamiento de datos. Por ejemplo, en GUI, bases de datos y páginas JSP.

6.2 JSP y JavaBeans

Una de las razones del JSP fue que podría subcontratarse a desarrolladores front-end. ¿Y qué? Tiene una persona que entiende HTML, déjelo escribir JSP. Los programadores de Java escriben su parte, los desarrolladores front-end escriben la suya, todo está bien.

Y todo estuvo bien hasta que los desarrolladores front-end tuvieron que entender el código Java escrito incrustado en el JSP. O, peor aún, escriba dicho código usted mismo.

Los programadores de Java tampoco estaban contentos con esto. Bueno, por favor dime, ¿qué diseñadores de diseño son desarrolladores de back-end? Sí, no pueden escribir nada excepto guiones. Sí, y todo el paradigma de la programación dice que mezclar diferentes lenguajes en un solo archivo es una mala forma.

Entonces surgió la idea que dicen de darle a los desarrolladores front-end la oportunidad de trabajar con objetos Java, como con código HTML. Cada etiqueta HTML es también un objeto con sus propios campos, ¿por qué no trabajar con objetos Java de forma similar?

Dicho y hecho. Se agregaron etiquetas especiales y listo.

Creación de objetos:

<jsp:useBean id="Name" class="Object type" scope="session"/>

Este comando creó un objeto con el tipo objecty lo puso sessionbajo el nombre Name.

Los objetos pueden almacenarse en uno de cuatro almacenes: aplicación (global), sesión, solicitud y página. También fue posible establecer una propiedad de tales objetos:

<jsp:setProperty name="Name" property="propName" value="string constant"/>

Podría obtener la propiedad de tales objetos como este:

<jsp:getProperty name="Name" property="propName"/>

Un ejemplo de uso de etiquetas:

<body>
    <center>
        <h2>Using JavaBeans in JSP</h2>
        <jsp:useBean id = "test" class = "com.example.TestBean" />
        <jsp:setProperty name = "test" property = "message" value = "Hello JSP..." />
        <p> What-to do important</p>
        <jsp:getProperty name = "test" property = "message" />
    </center>
   </body>