Buscar
Social
Ofertas laborales ES

Foro sobre Java EE > [JSF] Invocación a action dinámica

Buenas.

Estoy intentando hacer algo un poco rebuscado, y no se si JSF (MyFaces - Trinidad)tiene alguna herramienta que me permita hacerlo.

Lo que quiero es un commandButton (o commandLink) que ejecute un action, pero que este action sea "parametizable".
A ver si consigo explicarme...

Tengo un
<tr:commandButton action="#{bean.action}"/>

Bueno, pues quiero poder indicar el nombre del bean y el nombre del action a ejecutar, y que estos sean unos datos más, y no invoque siempre al mismo bean, ni al mismo action. Algo en plan...

<tr:commandButton action="#{nombreBeanConfigurado}.#{nombreMetodoAction}"/>
y que JSF ejecute el action, redirija a la pantalla que tenga configurada... etc.

¿Sabeis si es posible hacerlo con JSF?.

Un saludo.

octubre 3, 2012 | Unregistered CommenterMayantigo

Hola.

Hace tiempo tenia algo como :

ice:commandButton action="#{bean.action}" style="color: #a6a6a6"

y necesitaba que el style fuera dinamico ( osea que cambie de color ), asi que dentro del managed bean hice esto :

String myStyle = "color: #a6a6a6":

y en vista hice esto:

ice:commandButton action="#{bean.action}" style="#{bean.myStyle}"

y funciono :) !!

Si analizamos un poco, el parametro style necesita un "string" y se le puede poner ese
string en duro o dinamico. Puede ser que el parametro action tambien necesite un string
que le indique cual es el managed bean y cual es el action, si es asi podras hacer que sea
dinamico.

Prueba con el action y nos cuentas como te fue, si puedo yo tambien intentare :) !!

octubre 4, 2012 | Registered Commenterjrichard

Me da la impresión que lo que pretendes hacer se consigue sin tanto problema en el lado del backing bean.

Ya sabemos cual es tu solución al problema, ¿Por que no nos dices ahora cuál es le problema?

octubre 4, 2012 | Registered Commenterantoniovl

Pensaba hacerlo en el backing bean. El problema (o casuística, mejor dicho) es el siguiente. Intentaré expilcar lo que quiero (tengo que) hacer.

La aplicación es una especie de "core" que gestiona módulos. Los módulos son "jar" empaquetados, que al final no son más que formularios que se cargan desde el core.

Imaginaos una pantalla con una lista de formularios. Cada formulario tiene un botón "Editar". Ese "Editar" se configura desde una administración de módulos, y se selecciona el módulo que va a gestionar ese formulario. Si lo hago en el backing bean, que me calcule a que "xhtml" tengo que saltar, el backing bean de ese formulario no tendrá ningún dato precargado.

He visto aplicaciones donde hay cosas parecidas, en mi trabajo, y en todas se ha tenido que implementar la recuperación de datos y combos en los propios métodos "get", al hacer un salto sin ejecutar el "action" propio de inicio de ese backing bean (no se si me estoy explicando correctamente).

JSF llama muchas veces a un método "get" durante su ciclo de vida, por lo que se nota en el rendimiento de la aplicación muchísimo.

Entonces la idea era calcular el "action" y backing bean a ejecutar en ese punto, para hacerlo a través del flujo de JSF de forma más transparente.

¿Me he explicado bien?. ¿Se os ocurre alguna otra alternativa?.

Un saludo.

octubre 5, 2012 | Unregistered CommenterMayantigo

Hola Mayantigo.

Y si haces un xhtml con 6 commandbutton (imaginando que tienes 6 formularios). Con el commandbutton podrias irte a cualquier otro xhtml o hacer lo que desees.

Saludos

octubre 5, 2012 | Registered Commenterjrichard

Imaginaos una pantalla con una lista de formularios. Cada formulario tiene un botón "Editar". Ese "Editar" se configura desde una administración de módulos, y se selecciona el módulo que va a gestionar ese formulario. Si lo hago en el backing bean, que me calcule a que "xhtml" tengo que saltar, el backing bean de ese formulario no tendrá ningún dato precargado.

He visto aplicaciones donde hay cosas parecidas, en mi trabajo, y en todas se ha tenido que implementar la recuperación de datos y combos en los propios métodos "get", al hacer un salto sin ejecutar el "action" propio de inicio de ese backing bean (no se si me estoy explicando correctamente).

No te estoy entendiendo bien. Puedes refererirme a un ejemplo que pueda ver?

JSF llama muchas veces a un método "get" durante su ciclo de vida, por lo que se nota en el rendimiento de la aplicación muchísimo.

Puedes utilizar algo que por allí denominaron "lazy property loading" (nada que ver con el Lazy Loading de Hibernate). Es algo como;


private AlgunObjeto algunObjeto;

public AlgunObjeto getAlgunObjeto() {
if (this.algunObjeto == null) {
// .... obtienes el valor que deseas colocar en el objeto
}
}

De esa forma invocas 6 veces el método getAlgunObjeto() pero solamente una vez entrará a inicializar el objeto (tal vez cargarlo desde una base de datos, que puede ser una operación computacionalmente costosa).

Hay quienes están en contra de colocar este código en los getters y prefieren colocar un metodo loadData() para cargar todos los valores. Será cuestión de enfoques.

octubre 5, 2012 | Registered Commenterantoniovl

No te estoy entendiendo bien. Puedes refererirme a un ejemplo que pueda ver?"

A ver si consigo explicarme. Tenemos un módulo "war" central, que hace de nucleo. Ese war lo liberamos, para que cualquiera pueda hacer uso de él. La aplicación, por la funcionalidad que ofrece, permite a terceros desarrolladores hacer módulos y extender la aplicación.

Este nucleo permite crear entradas de menú para cada módulo (que se despliega en el "lib" del "war" empaquetado en un jar). La cosa es que al pulsar en esa entrada de menú, debe ejecutar un método para redirigir a la página inicial de ese módulo.

Normalmente una página necesita recuperar de base de datos ciertos parámetros, o a través de servicios web, o como sea.
El problema es que esos módulos no solemos hacerlos nosotros, sino otros desarrolladores que usan nuestro "core". Y pueden hacer verdaderas "barbaridades". Como el producto es nuestro, pues también nos afecta la calidad de los módulos que hacen.
Así que para eso hemos hecho un pequeño "framework", que deben utilizar los desarrolladores. Entre las clases que tienen que utilizar, hay un "BackingBeanGenerico" abstracto (no se llama así, pero más o menos). Este backing bean va a tener métodos abstractos, que los desarrolladores tendrán que "rellenar", y que serán los que invoque nuestro "core", para seguir un orden y que no se lie mucho.
Uno de esos métodos es el "inicializar".

Puedes utilizar algo que por allí denominaron "lazy property loading" (nada que ver con el Lazy Loading de Hibernate).

Podríamos delegar en los desarrolladores, y que usen el "lazy property loading", pero no todos lo hacen. La mayoría hacen backing beans gigantes, que contienen toda la lógica de negocio.

Así que la idea era "forzar" a que usen buenas prácticas de programación, y "facilitarles" el trabajo.

Estoy viendo el evento:
<f:event="preRenderView" />
Que está disponible en JSF 2, y quizá por ahí podríamos ver algo.

Ya digo, que alternativas las tenemos, pero la idea era hacerlo todo un poco más "fluido". Que luego cuando revisamos los códigos encontramos cada cosa...

Un saludo y gracias por vuestras respuestas.

octubre 8, 2012 | Unregistered CommenterMayantigo

Hola:

Me encuentro en el ambiente java soy principiante, me gustaria saber como puedo dibujar un formulario de forma dinamica desde el bea, como asi?. estoy utilizando la cadena de responsabilidad y lo que hago es que leo un archivo xml donde me retorna el tipo de objecto que tengo que crear (OutpuText, DataTable. etc...) pero deseo comenzar a saber como hago para que desde el pagina.xhtml pueda hacer que se ejecute esta cadena de responsabilidad.... no se si me entienden. por que ya lo intente con el value con el binding y no me funciona... :(

diciembre 10, 2012 | Unregistered CommenterFardul