Personalmente, usaría la Opción # 2. Si bien sé que es muy posible resolver el problema usando EL y obtener un poco de reutilización en los documentos xhtml usando funciones o ui: params, parece que realmente carece de la portabilidad, mantenibilidad y capacidad de prueba de la implementación del bean Java.
Si un desarrollador tiene fluidez tanto en EL como en Java y posee los beans xhtml y Java, no parece tener mucho sentido usar EL para hacer CUALQUIER evaluación condicional con un tamaño> 1.
Parece que hay demasiados beneficios para implementar en el lado de Java:
- Capacidad para apoyarse en el compilador IDE +
- Use constantes o enumeraciones (para "perro" y "ladrido"), lo más probable es que también se usen en otras partes del código para realizar comparaciones ... si el valor de la cadena cambia, es realmente divertido tener que reemplazar manualmente cada aparición en un base de código
- En lugar de tener que navegar a la página en cuestión con los datos apropiados, puedo ejercitar la lógica usando pruebas unitarias
Uno de los principales argumentos que he escuchado (fuera de Stack) a favor de la Opción 1 es:
"Es mucho más fácil ver cuándo se procesa un componente si mantiene esta lógica en la vista".
Descubrí que este podría ser el caso de una aplicación en la etapa inicial de su vida, donde es más liviana y menos complicada. Sin embargo, la aplicación de esta práctica a mayor escala y a medida que una aplicación más pequeña madura puede causar un nido de ratas condicionales y convertirse en una pesadilla para mantener. Aquí hay un par de ejemplos similares a los que he visto en la naturaleza:
<h:outputText value="grrr"
render="#{animal.type == 'dog' or animal.type == 'cat' or animal.type == 'horse'
or animal.type == 'pony' or animal.type == 'mule' or animal.type == 'lion'
or animal.type == 'tiger' or (animal.type == 'bird'
and animal.subType == 'macaw') or .... continue this for another line or two}"
/>
O mi favorito, usar múltiples componentes con condiciones de representación que son exclusivos entre sí para representar los diferentes valores que se pueden mostrar:
<h:outputText value="grr" render="#{theMonstrosityFromPreviousExample} />
<h:outputText value="cry"
render="#{animal.type == 'human' and animal.subType == 'baby'}" />
<h:outputText value="yo"
render="#{animal.type == 'human' and animal.subType == 'teenager'}" />
<h:outputText value="hello"
render="#{animal.type == 'human' and animal.subType == 'adult'}"/>
¿Se pueden mostrar hasta 4 textos a la vez? A primera vista no se puede ver, será necesario verificar cada condición. Como nota al margen, me doy cuenta de que este ejemplo también tiene un diseño deficiente, ya que estos podrían ponerse en ac: elegir ... pero ya he visto esto antes.
Al final del día, esto sigue siendo teóricamente una lógica de "vista", ya que determina lo que realmente se muestra, por lo que hay un argumento conceptual que debería vivir en el xhtml. El problema que he encontrado es que incluir una lógica como esta en la plantilla de vista puede hacer que el diseño sea mucho más difícil de entender a largo plazo y todavía tengo que ver que este método para resolver el problema tiene un beneficio real sobre el uso de Java implementación de frijol.
barking animals
porque llamaría a ese método, ya que ya existe. Si se trata de una lógica de vista que utiliza en varios sitios, puede crear una función el a partir de ella.