Desarrollo Web con componentes: Componentes en Wicket

Segundo ejemplo de Wicket: Calculadora

El ejemplo lo pueden encontrar acá.

Veamos ahora la división según MVC:

1. El usuario solicita la página: antes de renderizar la página html al cliente ya tenemos nuestro controller con:
   1. un objeto calculadora instanciado (operando1 y operando2 en 0.0)
   2. textfields asociados a operando1 y operando2
   3. un button asociado al submit de sumar
2. En el cliente se visualiza 0 en ambos operandos
3. El usuario ingresa 7 en el operando1, 9 en el operando2 y presiona el botón Sumar
4. Se submite el formulario al Server, entonces se acciona el controller. El form de wicket setea al model todas las propiedades al model:
   1. en el operando1 de Calculadora se asignó 7.0 (setOperando1)
   2. en el operando2 de Calculadora se asignó 9.0 (setOperando2)
5. Se envía el mensaje sumar() al objeto calculadora que es modelo de dominio
6. Al sumar se actualizan los operandos 1 y 2
7. Se refresca la página, entonces se llena la información del form html nuevamente (con la información de la calculadora.java):
   1. en el input type text operando1 se setea el valor de operando1 (getOperando1)
   2. en el input type text operando1 se setea el valor de operando2 (getOperando2)
   3. en el span resultado se setea el valor de resultado (método String getResultado())

• No hace falta que la calculadora mantenga un estado para el resultado, basta con que exista un método getResultado (es una property read-only).
• Como vemos hay un "maridaje" en la asociación Controller Wicket-View HTML:
  • Form-Form (!)
  • Label-Span,
  • TextField-Input Type Text
  • ListView-Tabla HTML (como pueden ver en el mismo ejemplo de la búsqueda de libros)
  • en general hay que respetar la misma jerarquía del HTML, eso lo vuelve poco flexible (no es transparente el rediseño de la vista)
• Cambiar de input type=submit a input type=button produce que los controles no reciban los valores que cargó el usuario en pantalla (no viajan por el request, pruébenlo: los operandos quedan en cero). Este es un incoveniente propio del protocolo, que lamentablemente Wicket no esconde (la metáfora tiene un límite).
• Por otra parte, si se carga un operando con valores alfabéticos solito el wicket te muestra el error en formato de viñetas.
• Cada control observa la propiedad del modelo, esto es bueno porque no tengo que encargarme de codificar el binding: basta con seguir la convención de darle el mismo nombre en la vista html, en el controller de wicket y en el modelo de dominio (como pasa por ejemplo con el operando1 y operando2). Pero la actualización no es instantánea, esto sólo puede ocurrir cuando el usuario haga submit del form.
• Se puede debuggear para ver que al llamar a sumar() cada control observa la propiedad del modelo y en consecuencia se refresca.

Números aleatorios

Este proyecto es numerosRandom-ui-wicket y tiene el siguiente layout:

Es interesante notar que el HomePage actúa de container, generando un Composite de controles.

No hay un model aún, porque vamos a trabajar más granularmente, a nivel componente: