© Copyright International Business Machines Corporation 2006. Reservados todos los derechos. US Government Users Restricted Rights - Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM® Corp.
Lo siguiente ha caído en desuso y por tanto no se recomienda su utilización:
- Datos de cliente y herramientas asociadas (como la vista Datos de cliente)
- Componentes de Cliente Faces
<odc:dataGrid>
(Cuadrícula de datos)<odc:webService>
(Servicio Web)<odc:clientData>
<odc:clientBinder>
El árbol
<odc:tree>
y el diagrama<odc:graphDraw>
se han habilitado para utilizar Datos de servidor.
Si importa una aplicación JSF anterior a la V7 sin migrar los JAR de JSF y continúa desarrollando la aplicación, los códigos nuevos de la V7 no se incluirán en los JAR del proyecto ni estarán disponibles en tiempo de ejecución. Asegúrese de migrar los JAR anteriores a la V7.
El código
<odc:treeNodeAttr>
del control del árbol utiliza valores diferentes para el atributo className cuando está vinculado a datos SDO y cuando lo está a datos WDO. Después de migrar un proyecto de un servidor que utiliza WDO (como por ejemplo WebSphere® Application Server 5.1) a uno que utiliza SDO (como por ejemplo WebSphere Application Server 6.1), la forma más sencilla de arreglar esto consiste en suprimir y recrear controles de árbol.
En v6.0, si un
<hx:commandExButton>
tenía el tipo establecido en Submit y tenía una etiqueta y solo una imagen de fondo (por ejemplovalue="submit" image="button.gif"
), solo se interpretaba la imagen (no la imagen y la etiqueta.) Este problema se ha arreglado en v7.0. El arreglo implica que los botones que tienen una etiqueta y una sola imagen de fondo se interpretarán de forma distinta con v7.0 que con v6.0.Del mismo modo, si un
<hx:commandExButton>
tenía el tipo establecido enReset
y solo una imagen de fondo (o una imagen de fondo y una etiqueta), solo se interpretaba la imagen, y el botón se trataba como botón de someter (se omitía el tipo de botón.) Este problema se ha arreglado en v7.0. El arreglo implica que los botones marcados con el tipo establecido enReset
restablecerán ahora la página en lugar de someterla.
Los atributos del código
<jspPanel>
style
ystyleClass
ya no están disponibles. Los atributos no se utilizan para interpretar el componente del panel JSP.Si importa una aplicación JSF creada en una versión anterior de este producto, los códigos
<jspPanel>
mostrarán errores. Para resolver los errores, elimine los atributosstyle
ystyleClass
de los códigos<jspPanel>
del proyecto editando el código fuente de JSP en la vista Fuente.
Si importa proyectos en el espacio de trabajo creados mediante una versión anterior del producto, verá un diálogo emergente que indica que se ha instalado el soporte Faces pero que no se ha seleccionado ningún tiempo de ejecución destino para el proyecto. En algunos casos, este aviso no es exacto y se definirá un tiempo de ejecución correctamente cuando finalice el proceso de migración. Para comprobar si un tiempo de ejecución está establecido pulse con el botón derecho sobre Proyecto > Propiedades y seleccione Tiempos de ejecución destino. Si hay una marca de selección junto a alguno de los servidores definidos, no es necesaria ninguna acción más, de lo contrario, seleccione uno de los servidores.
Nota: esta solución no es necesaria cuando se crean modelos de cliente del mismo nodo de datos de página o nodos de página del mismo nombre.
En v7.0, cuando hay varios modelos de datos de cliente en la página creados de las mismas clases de bean, se creará erróneamente un segundo archivo ecore y emap para el segundo modelo después de la generación (o regeneración.) Según la guía de migración, al migrar proyectos de datos de cliente, los modelos de datos de cliente deben regenerarse para que esto pueda afectar a proyectos migrados con páginas que contienen más de un modelo de datos de cliente. A continuación se proporciona un caso de ejemplo simple:
- Cree dos datos de página basados en el bean java.util.Date, por ejemplo myDate1 y myDate2.
- Para cada uno de los datos de página, cree un modelo de datos de cliente del mismo nombre por el orden siguiente: myDate1 y después myDate2.
Solución provisional: para obtener una página que funcione con ambos modelos, suprima myDate2.ecore y myDate2.emap del paquete com.ibm.dynwdo4jsmediators y las entradas correspondientes en el archivo OdysseyBrowserFramework.properties.
Los Datos de cliente sacan una gran cantidad de JavaScript a una página. En releases anteriores el JavaScript no estaba codificado. Esto significaba que si estaba utilizando Datos de cliente en varios portlets con el mismo origen de datos de página, la salida JavaScript a la página sería igual para todos los portlets.
Este comportamiento, en el que dos portlets se enlazan a Datos de cliente puede parecer que enlaza con el mismo objeto de Datos de cliente (ya que la segunda sección del JavaScript sobrescribirá la primera.) Esto a su vez, permite que ambos portlets interactúen de modo que un cambio en uno de ellos se representará en los dos.
Esto es problemático si desea tener varios portlets en una página que utiliza Datos de cliente que funcionan independientemente uno de otro. Se producen errores de JavaScript cuando tiene dos portlets que utilizan Datos de cliente en la misma página con orígenes de datos de página diferentes. Esto también puede provocar que no se interprete uno de los portlets.
Para arreglar estos problemas y permitir que los Portlets de datos de cliente se ejecuten sobre WSRP, las variables JavaScript de datos de cliente deben codificarse para que sean exclusivas de cada portlet. Esto permite que las secciones de JavaScript de Datos de cliente funcionen independientemente una de otra.
En V7.0, se codificarán todos los datos de cliente.
Si desea compartir Datos de cliente entre portlets en una página, debe actualizar web.xml con los parámetros de contexto siguientes:
<context-param>
<param-name>com.ibm.faces.ENCODE_DATA</param-name>
<param-value>false</param-value>
<description></description>
</context-param>Al establecer <param-value> en false, está eliminando la codificación de Datos de cliente.
Utilización del parámetro Encode_Data y su efecto sobre los componentes Diagrama y Árbol de datos que utilizan Datos de página
El Diagrama y el Árbol de datos utilizan datos de página poniendo un objeto de datos XML en la página. Los Datos de página para el Diagrama y el Árbol de datos están estrechamente ligados a Datos de cliente para estos componentes. Estos datos están codificados de forma predeterminada. Si establece el <context-param> que se muestra más abajo en el archivo web.xml, que normalmente se utiliza para eliminar la codificación de Datos de cliente, también eliminará la codificación de Datos de página para el Diagrama y el árbol de datos. No se verá afectado ningún otro componente que utilice datos de página. Dejar los datos sin codificar significa tener dos portlets en una página, donde ambos contienen un Diagrama o un Árbol de datos, lo que puede originar problemas. Estos errores incluyen errores de JavaScript y/o uno de los portlets que no se visualiza adecuadamente.
Al igual que ocurre con los Datos de cliente para codificar estos datos, permitir que dos portlets se ejecuten en una página independientemente uno de otro y habiliten el soporte WSRP, deberá eliminar el siguiente <context-param> de web.xml o establecer <param-value> en true:
<context-param>
<param-name>com.ibm.faces.ENCODE_DATA</param-name>
<param-value>true</param-value>
<description></description>
</context-param>
Esto está situado en la parte superior de la página:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
Esto origina que los navegadores utilicen la modalidad estándar. En la modalidad estándar los elementos
HTML
ybody
se ajustan a su contenido en lugar de ocupar toda la ventana como ocurre en la modalidad quirks (la modalidad HTML predeterminada.)Cuando un panel con pestañas se coloca en la página por sí mismo con la altura establecida en un porcentaje, se producirán problemas de visualización con la altura del panel.
Para arreglar este problema, coloque el panel con pestañas en un contenedor que tenga una altura establecida o cambie el doctype del principio de la página por lo siguiente:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
Hay problemas de visualización con las pestañas en la modalidad estándar cuando el doctype está establecido en lo siguiente:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
Esto se rectifica cambiando el doctype en:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
El código
<hx:convertDateTime>
no genera JavaScript correcto cuando el tipo de calendario se ha establecido en árabe. Como resultado, la validación del lado del cliente, la solicitud de entrada, el ayudante de selección de datos y el minicalendario no funcionan correctamente. Cuando se inicializa el JavaScript generado, se muestra un error (o el componente no funciona correctamente.)Solución provisional: No active la solicitud ni la validación del lado del cliente. No active el ayudante de selección de datos si se utiliza el calendario árabe con el conversor.
Cuando el tiempo de ejecución destino sea el servidor WebSphere®, asegúrese de que la faceta del proyecto Web de WebSphere (Coexistencia) esté seleccionada para el proyecto Web.
Solución provisional: seleccione la faceta en la segunda página del asistente Proyecto Web dinámico al crear el proyecto o hágalo a través de la página Facetas de proyecto del diálogo Propiedades del proyecto si el proyecto ya existe. Al crear un proyecto Web destinado a un servidor WebSphere, si selecciona "Proyecto Faces" o "Proyecto Web dinámico con XDoclet" en la lista desplegables de la primera página del asistente del proyecto, la faceta Web de WebSphere (Coexistencia) no se seleccionará automáticamente. Puede pasar a la página siguiente del asistente para seleccionar esta faceta. Si selecciona "<custom>" en la lista Configuraciones, la faceta se seleccionará adecuadamente cuando el tiempo de ejecución destino sea WebSphere.
Cuando se utiliza
<hx:columnEx>
en<hx:dataTableEx>
y el desplazamiento vertical está habilitado (scrollSize está establecido), si una o varias de las columnas de la tabla tiene la anchura establecida como anchura basada en porcentaje, en la tabla interpretada, las cabeceras y el contenido de las columnas no estarán alineados entre sí si el doctype de la página lo interpreta el navegador como W3C estándar (en lugar de W3C transicional.) Por ejemplo, esto ocurrirá si el doctype incluye una declaraciónloose.dtd
.
Solución provisional: haga fijas las anchuras de las columnas (no basadas en porcentaje) o asegúrese de que el doctype se resuelve en un doctypetransitional
(por ejemplo, elimine la declaración loose.dtd.)
En un
<hx:panelDialog>
, si el posicionamiento (horizontal o vertical) se establece enrelative
y el código utilizado como base para el posicionamiento (el código frente al que el diálogo se posiciona como relativo) está en una página que se desplaza de modo que el código se visualiza y la página no se desplaza hasta el final, cuando se visualiza el diálogo, se posicionará incorrectamente (normalmente estará situado demasiado lejos hacia arriba o demasiado lejos hacia la izquierda.)Solución provisional: si se necesita el posicionamiento relativo, asegúrese de que el código base esté situado junto a la parte superior de la página. También puede utilizar uno de los otros tipos o posicionamiento.
Si una tabla de datos (ya sea
<h:dataTable>
o<hx:dataTableEx>
) está en un panel habilitado para AJAX y está habilitada para para selección de filas (<hx:inputRowSelect>
está incluido en la tabla), los recuadros de selección de la columna de selección no funcionarán correctamente cuando se vuelva a extraer la tabla a través de AJAX. No funcionará correctamente la primera vez (solo) que se interprete.Solución provisional: actualmente no hay ninguna solución para este problema. No ponga la tabla en un panel habilitado para AJAX.
<hx:ajaxExternalRequest>
no funcionará correctamente en Internet Explorer (IE) si el atributo origen utilizado para especificar el ID del panel a recuperar en la página destino difiere del ID del panel al que está conectado<hx:ajaxExternalRequest>
en la página origen. Por ejemplo<hx:panel id="panel1"><hx:ajaxExternalRequest source="panel999" /><hx:panel>
. El problema solo se produce en IE y solo si el panel destino es una cuadrícula, un recuadro o un diseño (un panel que se interpreta como una tabla HTML.)Solución provisional: asegúrese de que los ID sean los mismos o envuelva el panel destino en un panelGroup.
El atributo
inProgresss
para<hx:ajaxRefreshRequest>
,<hx:ajaxRefreshSubmit>
,<hx:ajaxExternalRequest>
y<hx:inputHelperTypeahead>
no funciona. Establecimiento un valor para este atributo no surte ningún efecto. Para asegurar la compatibilidad con releases posteriores, no establezca el valor.
Cuando
<hx:inputHelperTypeahead>
se conecta código a un campo de entrada, si se especifica en el campo un carácter de espacio y/o caracteres de puntuación como por ejemplo caracteres & y porcentajes, la lista de sugerencias construida no incluirá "coincidencias" que incluyan estos caracteres. Por ejemplo, si un usuario teclea %, no se devolverán coincidencias incluso aunque haya palabras en el "diccionario" en uso que empiecen por %.
Un cambio del comportamiento de algunos atributos HTML DOM a partir de la versión 1.5.0.8 de Firefox puede hacer que un
panelDialog
no se posicione correctamente cuando se interprete en Firefox. El problema más común ocurre cuando un diálogo tiene una posición relativa pero puede ocurrir en otros casos en los que el tamaño del contenido del cuerpo sea "menor que" la altura de la ventana del navegador (es decir, cuando la página no se desplaza verticalmente.)Solución provisional: añadir contenido al cuerpo (incluso con espacios en blanco como por ejemplo un <div> con la altura establecida) de modo que la barra de desplazamiento vertical esté siempre en la página puede solucionar el problema (esto depende de las dimensiones exactas de la ventana del navegador y del contenido.)
<hx:pagerDeluxe>
no interpreta el código HTML si styleClass se establece en otra cosa que no sea la clase predeterminadapagerDeluxe
. Los botones del paginador se interpretarán siempre con nombres de clase que utilicen el nombre de clase predeterminado en ellos.Solución provisional:
- No cambie el nombre de clase por otra cosa que no sea pagerDeluxe.
- Ajuste la CSS utilizada para que tenga en cuenta los nombres de clase interpretados en los botones si se utiliza un nombre de clase diferente.