Ejemplo práctico de como usar jQuery en ADF, en este caso como cambiar el type de un inputText para el caso de querer mostrar los caracteres de un campo contraseña.
<af:resource type="javascript"
source="https://ajax.googleapis.com/ajax/libs/jquery/1.12.4/jquery.min.js"/>
<af:resource type="javascript">
function showPasswordMethod(e) {
var inputPassword1 = $("input[id*=it2]")[0];
if (inputPassword1.type == "text") {
inputPassword1.type = "password";
$("img[id*=imgShowPassword]")[0].src = "/webcenter/../wcstatic/img/genericas/eye_black.png";
}
else {
inputPassword1.type = "text";
$("img[id*=imgShowPassword]")[0].src = "/webcenter/../wcstatic/img/genericas/eye_red.png";
}
}
</af:resource>
<af:inputText label="Contraseña actual" id="it2" required="true" styleClass="resetPasswordField oldpwd" value="#{resetPasswordBean.oldpassword}"
secret="true" autoComplete="off"/>
<af:image source="/../wcstatic/img/genericas/eye_black.png" id="imgShowPassword" inlineStyle="position: absolute;bottom: 190px; right: 14px; cursor: pointer;">
<af:clientListener method="showPasswordMethod" type="click"/>
</af:image>
Apuntes, curiosidades y utilidades sobre tecnología Oracle, Java y software en general.
Mostrando entradas con la etiqueta ADF. Mostrar todas las entradas
Mostrando entradas con la etiqueta ADF. Mostrar todas las entradas
jueves, 27 de febrero de 2020
miércoles, 20 de febrero de 2019
Atributo ClearCacheOnCommit en ADF
En un desarrollo reciente disponemos de una tabla ADF con varios registros, basado en un VO Entity updatable en donde se puede operar con acciones CreateInsert y Delete, con su posterior Commit, cada row con un atributo PK independiente.
Nos surgió la problemática de que, sin salir de la taskflow, al realizar el CreateInsert y a continuación realizar el Delete de esa misma row (con las opciones out of the box de binding mediante getCurrent) veíamos como se borraba de la tabla pero no de base de datos.
¿Cual era el problema? Para explicarlo mostramos el ciclo de vida de ADF:
Cuando se realiza la operación CreateInsert, se inserta y accede al binding correspondiente, se accede al AppModule y se inserta en base de datos, pero no se actualiza el datacontrol con dicha información, es decir, se inserta la row en el iterator pero no ha refrescado con la PK que ha devuelto la base de datos, por lo que la row insertada y que se ve en la tabla no tiene actualizado el campo PK devuelto por el modelo.
Como se puede deducir, si no refrescas el iterator o pides de nuevo los datos a la base de datos, esa row no se actualiza con su verdadero PK por lo que al borrar inmediatamente después lo va a borrar del iterator pero no de base de datos.
La solución consiste en usar el atributo ClearCacheOnCommit en el fichero AppModule de nuestra aplicación:
Dicho atributo permite refrescar los VO después de realizar la operación Commit, por lo que siempre vamos a tener en este caso deseablemente el valor introducido en base de datos.
Si no se refleja esta variable en el AppModule, por defecto no aparecerá y tomará el valor "false", como se indica en la documentación (esto es del método isClearCacheOnCommit de la interfaz Transaction para consultar dicho valor):
Nos surgió la problemática de que, sin salir de la taskflow, al realizar el CreateInsert y a continuación realizar el Delete de esa misma row (con las opciones out of the box de binding mediante getCurrent) veíamos como se borraba de la tabla pero no de base de datos.
¿Cual era el problema? Para explicarlo mostramos el ciclo de vida de ADF:
Cuando se realiza la operación CreateInsert, se inserta y accede al binding correspondiente, se accede al AppModule y se inserta en base de datos, pero no se actualiza el datacontrol con dicha información, es decir, se inserta la row en el iterator pero no ha refrescado con la PK que ha devuelto la base de datos, por lo que la row insertada y que se ve en la tabla no tiene actualizado el campo PK devuelto por el modelo.
Como se puede deducir, si no refrescas el iterator o pides de nuevo los datos a la base de datos, esa row no se actualiza con su verdadero PK por lo que al borrar inmediatamente después lo va a borrar del iterator pero no de base de datos.
La solución consiste en usar el atributo ClearCacheOnCommit en el fichero AppModule de nuestra aplicación:
Dicho atributo permite refrescar los VO después de realizar la operación Commit, por lo que siempre vamos a tener en este caso deseablemente el valor introducido en base de datos.
Si no se refleja esta variable en el AppModule, por defecto no aparecerá y tomará el valor "false", como se indica en la documentación (esto es del método isClearCacheOnCommit de la interfaz Transaction para consultar dicho valor):
isClearCacheOnCommit
public boolean isClearCacheOnCommit()
- Returns the flag indicating whether all Entity Object caches will be cleared after the transaction is committed.After the transaction is committed, the value of this flag is used to determine whether the Entity Object caches are cleared or not. If this flag value is
false, the cache contents are kept. In this case, the cache may contain data that is stale in that it does not match the newest data (changes made by another user and committed).
If this flag istrue, the caches are cleared after the transaction is committed. When the user brings in data by traversing row collection, the latest data from the database will be brought into Entity caches. -
- Returns:
- the current value of clear-cache-on-commit flag.
- See Also:
RowSet.executeQuery(),setClearCacheOnCommit(boolean val)
viernes, 13 de mayo de 2016
Error al desplegar aplicación ADF en Weblogic nuevo
Cuando hemos montado un Weblogic que albergará aplicaciones ADF, la primera vez que intentamos desplegar nos aparece el error siguiente:
Error while processing library references. Unresolved application library references, defined in weblogic-application.xml: [Extension-Name: adf.oracle.domain, exact-match: false]
Esto es porque hay librerias de ADF de Weblogic que no se han aplicado a todos los destinos (en concreto al manejado de ADF). Para ello debemos asegurarnos que las siguientes librerías tengan aplicado como destino tanto el nodo Admin como el manejado:

Error while processing library references. Unresolved application library references, defined in weblogic-application.xml: [Extension-Name: adf.oracle.domain, exact-match: false]
Esto es porque hay librerias de ADF de Weblogic que no se han aplicado a todos los destinos (en concreto al manejado de ADF). Para ello debemos asegurarnos que las siguientes librerías tengan aplicado como destino tanto el nodo Admin como el manejado:
- adf.oracle.domain
- adf.oracle.businesseditor
- adf.oracle.domain.webapp
- jstl
- jsf
lunes, 9 de mayo de 2016
Login aplicación ADF
Vamos a ver un ejemplo sencillo de como realizar el login de una aplicación ADF, basándonos en que no necesitamos más que el DefaultAuthenticator de nuestro Weblogic.
Para ello, primeramente en la taskflow principal (adfc-config) debemos realizar una pantalla "login" donde el usuario introducirá sus datos:

La pantalla de login estará basada en un managedBean, de scope "Request" en la taskflow adfc-config.

Como hemos comentado, este será el aspecto de nuestra "login.jsf", donde los componentes estarán bindeados al managed bean como atributos de la clase, y el botón de Acceder será un método de la clase:

El input de la contraseña tendrá la propiedad "secret" para que no sea visible, y todos ellos tendrán autosubmit = true.
Por último, en el managedBean del login, implementaremos el metodo doLogin asociado al botón de Login:




Para ello, primeramente en la taskflow principal (adfc-config) debemos realizar una pantalla "login" donde el usuario introducirá sus datos:
La pantalla de login estará basada en un managedBean, de scope "Request" en la taskflow adfc-config.
Como hemos comentado, este será el aspecto de nuestra "login.jsf", donde los componentes estarán bindeados al managed bean como atributos de la clase, y el botón de Acceder será un método de la clase:
El input de la contraseña tendrá la propiedad "secret" para que no sea visible, y todos ellos tendrán autosubmit = true.
Por último, en el managedBean del login, implementaremos el metodo doLogin asociado al botón de Login:
Suscribirse a:
Entradas (Atom)