JSF, EL, Managed Beans - ¿Cómo saber qué son las firmas getter y setter?

Question

Con JSF, beans gestionados, & EL 2,2 sé en general, que una expresión de la forma:

#{bean.value} 

se asignarán a un conjunto correspondiente de funciones en una clase de bean administrado de esta manera:

@ManagedBean 
class Bean { 
    private String value; 
    public String getValue() { return value; } 
    public void setValue(String s) { value = s; } 
} 

también es posible obtener y establecer las propiedades de un mapa:

#{bean.value['key']} 

el respaldo de algo como:

@ManagedBean 
class Bean { 
    private Map<String, Boolean> kvMap; 
    public boolean getValue(String key) { return kvMap.get(key); } 
    public void setValue(String key, boolean value) { kvMap.put(key, value); } 
} 

Hasta ahora todo bien.

Estoy descubriendo que paso más tiempo con JSF pero estoy tratando de escribir trozos reutilizables de código. Específicamente, pequeños bloques de xhtml en <ui:composition> bloques que puedo incluir a través de <ui:include>. Además, muchas de las cosas más útiles para mí son cosas como conjuntos anidados de casillas de verificación (nuestro diseñador de interfaz de usuario simplemente se rebela sobre ellas ;-), y allí <ui:repeat> se vuelve muy útil.

Invariablemente, con el fin de utilizar <ui:repeat> y <ui:include> sin una cantidad impía de escribir, he estado usando alias, ya sea creados a través de <ui:param> o en línea con algo así como el atributo var de <ui:repeat>.

Como he estado escribiendo más y más UIComponents anidados, particularmente cosas que obtienen sus valores de los mapas dentro de los mapas, cada vez me resulta más difícil deducir la firma correcta del método setter que JSF buscará al enviar un forma (por alguna razón, escribir getters parece ser más natural).

Mi pregunta para los gurús entonces es:

¿Hay alguna manera de conseguir JSF me diga lo que espera una firma colocador para que parezca? Dado que JSF generalmente no se queja de una expresión que se resuelve como un getter (pensando que es una propiedad de solo lectura), encuentro que la falta de retroalimentación es frustrante y parece que es necesario manipular mucho con diferentes firmas de métodos antes de comenzar. finalmente golpeó esa magia a la derecha.

Espero que haya alguna técnica, por ejemplo, una consulta FacesContext ... en tiempo de ejecución o buscar en algún intermediario compilado como un archivo de clase que apunte a la firma del colocador correcto para una propiedad profundamente anidada. Si hay tal cosa, creo que me ahorraría mucho tiempo tratando de encontrar la forma de construir un setter por prueba y error.

Espero haber expresado claramente lo que busco, gracias de antemano por sus respuestas.

Answer 1

Entiendo que su pregunta básicamente se reduce a "¿Cómo debería ser un setter para un Map?".

La respuesta es simple: no necesita a nadie. EL usa el método put() en el Map. Solo necesita proporcionar un getter para todo Map. Al obtener los valores del mapa, EL utilizará el método get() del Map. Esto es todo detrás de las escenas realizadas por el built-in MapELResolver.

lo que este debe hacer:

@ManagedBean 
class Bean { 
    private Map<String, Boolean> kvMap; 
    public Map<String, Boolean> getValue() { return kvMap; } 
} 

que es para ser utilizado como #{bean.value['key']} o #{bean.value.key} si la clave no contiene períodos. También puede usarlo en componentes de entrada también.

<h:selectBooleanCheckbox value="#{bean.value.key}" /> 

En cuanto a las herramientas, así, el JBoss Herramientas plug-in para Eclipse tiene un buen soporte para autocompletar EL JavaBeans normales, pero no puede llaves mapa de autocompletar. Además, Eclipse tiene sus propias instalaciones para autogenerar propiedades de frijol junto con getters y setters basados ​​en una lista o propiedades existentes.