© 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 está en desuso y no se recomienda su utilización:
- Datos de cliente y herramientas asociadas (como la vista de Datos de cliente)
- Componentes de Faces Client
<odc:dataGrid>
(Data Grid)<odc:webService>
(Web Service)<odc:clientData>
<odc:clientBinder>
El árbol
<odc:tree>
y la gráfica<odc:graphDraw>
se han habilitado para utilizar Server Data.
Si importa una aplicación JSF anterior a la V7 sin migrar los JAR de JSF para desarrollar la aplicación, los códigos que sean nuevos en la V7 no se incluirán en los JAR del proyecto y no estarán disponibles en el tiempo de ejecución. Asegúrese de migrar los JAR anteriores a la V7.
El código
<odc:treeNodeAttr>
del control de árbol utiliza distintos valores para su atributo className cuando se enlaza a datos SDO en lugar de a datos WDO. Después de migrar un proyecto desde un servidor que utiliza WDO (como WebSphere® Application Server 5.1) a uno que utiliza SDO (como WebSphere Application Server 6.1), la manera más sencilla de corregir esto es suprimir y recrear cualquier control de árbol.
In v6.0, si
<hx:commandExButton>
tiene el tipo establecido en Submit y tiene una etiqueta y una sola imagen de fondo (por ejemplovalue="submit" image="button.gif"
), sólo se generará la imagen (no la imagen y la etiqueta). Este problema está corregido en v7.0. El arreglo quiere decir que los botones tienen una imagen de etiqueta y una de fondo que se generarán de forma diferente cuando se utilizan con v7.0 de como hacían con v6.0.De forma similar, si
<hx:commandExButton>
tiene el tipo establecido enReset
y tenía sola imagen de fondo (o una imagen de fondo o una etiqueta), sólo se generará la imagen y el botón será tratado como un botón de envío (el tipo del botón se ignora). Este problema está corregido en v7.0. El arreglo quiere decir que los botones marcados con el tipo establecido enReset
restablecerán la página ahora en lugar de enviarla.
Los atributos
style
ystyleClass
del código<jspPanel>
ya no están disponibles. Los atributos no se utilizan para representar el componente del panel de JSP.Si importa una aplicación JSF creada en una versión anterior de este producto, los códigos
<jspPanel>
mostrarán errores. Para solucionar los errores, elimine los atributosstyle
ystyleClass
de todos los códigos<jspPanel>
del proyecto editando la fuente de JSP en la vista Fuente.
Si importa proyectos en el espacio de trabajo creados utilizando una versión anterior del producto, es posible que vea un diálogo emergente que afirma que el soporte de Faces se ha instalado pero que no se ha seleccionado ningún tiempo de ejecución de destino para el proyecto. En algunos casos, este aviso no es del todo exacto y se habrá definido correctamente un tiempo de ejecución una vez ha terminado el proceso de migración. Para comprobar si un tiempo de ejecución está establecido, pulse con el botón derecho del ratón sobre Proyecto > Propiedades y seleccione Tiempos de ejecución de destino. Si aparece un recuadro de selección junto a cualquier servidor definido no necesitará hacer nada más, de no ser así, seleccione uno de los servidores.
Nota: este método alternativo no es necesario donde los modelos de datos de cliente se creen a partir del mismo nodo de datos de página o nodos de datos de página con el mismo nombre.
En v7.0, cuando hay varios modelos de datos de cliente en la página, creados a partir de las mismas clases de bean, se creará un segundo archivo ecore y emap erróneamente para el segundo modelo al generarse (o volver a generarse). De acuerdo con la guía de migración, cuando se migren proyectos de datos de cliente, los modelos de datos de cliente deben generarse para que puedan afectar a los proyectos migrados con páginas que contienen más de un modelo de datos de cliente. Una situación sencilla sería la siguiente:
- Cree dos datos de páginas basados en el bean java.util.Date bean, por ejemplo myDate1 y myDate2.
- Para cada dato de página, cree un modelo de datos de cliente con el mismo nombre en el orden: myDate1 y entonces myDate2.
Método alternativo: 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.
Datos de cliente proporciona una gran cantidad de JavaScript™ a una página. En releases anteriores el código JavaScript no estaba codificado. Esto quiere decir que si estaba utilizando Datos de cliente en varios portlets, utilizando el mismo origen de datos de página, la salida de JavaScript a la página será la misma para todos los portlets.
Este comportamiento, donde dos portlets se enlazan a Datos de cliente, puede parecer que se enlaza al mismo objeto de Datos de cliente (ya que la segunda sección de JavaScript sobregrabará la primera). Esto, a su vez, permite que los dos portlets interactúen, por lo que un cambio en uno de ellos se vería representado en ambos.
Esto es problemático si tiene varios portlets en una página que utiliza Datos de cliente que funcionan independientemente uno del otro. Se producirán errores de JavaScript cuando tenga dos portlets que utilicen Datos de cliente en la misma página con distintos orígenes de datos de página. Esto también puede provocar que uno de los portlets no sea generado.
Para corregir estos problemas y permitir que los portlets de datos de cliente se ejecuten con WSRP, las variables Javascript de datos de cliente deben codificarse para que sean exclusivos para cada portlet. Esto permite que las secciones de JavaScript de datos de cliente funciones independientemente.
En V7.0, se codificarán todos los datos de cliente.
Si desea compartir los Datos de cliente entre portlets en una página, necesitará actualizar el archivo web.xml con los siguientes parámetros de contexto:
<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 sus efectos en los componentes Diagrama y Árbol de datos utilizando Datos de página
Diagrama y Árbol de datos utilizan datos de página colocando un objeto de datos XML en la página. Los Datos de página de Diagrama y Árbol de datos están íntimamente ligados a Datos de cliente de dichos componentes. De forma predeterminada estos datos están codificados. Si establece <context-param> como se muestra a continuación en el archivo web.xml, que normalmente se utiliza para eliminar la codificación de Datos de cliente, también eliminará la codificación Datos de página para Diagramas y Árbol de datos. Ningún otro componente que utilizan datos de página se verán afectados. Si deja los datos de página sin codificar tendrá dos portlets en una página, donde ambas contendrán un diagrama o un árbol de datos, puede causar problemas. Estos errores incluyen errores de JavaScript y/o uno de los portlets no está visualizándose correctamente.
Como para que Datos de cliente codifiquen estos datos, permitir dos portlets en una página se ejecuten independientemente el uno del otro y para permitir el soporte de WSRP, necesitará eliminar el siguiente <context-param> de web.xml o establecer <param-value> en true (verdadero):
<context-param>
<param-name>com.ibm.faces.ENCODE_DATA</param-name>
<param-value>true</param-value>
<description></description>
</context-param>
Esta se encuentra 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 hace que los navegadores Web entren en modalidad estándar. En modalidad estándar, los elementos
HTML
ybody
se ajustan al contenido en lugar de llenar la ventana como se produce en modalidad quirks (la modalidad HTML estándar).Cuando un panel con pestañas se coloca en la página por si solo con su altura establecida en un porcentaje provocará problemas con la altura del panel.
Para corregir esto, coloque el panel con pestañas en un contenedor que tenga la altura establecida o cambie doctype en la parte superior de la página:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
Existen problemas de visualización con las pestañas en modalidad estándar cuando se establece doctype en:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
Esto puede corregirse cambiando doctype a:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
El código
<hx:convertDateTime>
no genera código JavaScript correcto cuando el tipo de calendario se establece en árabe. Como resultado, la validación del lado del cliente, solicitud de entrada, el ayudante de selector de fechas y el minicalendario no funcionan correctamente. Cuando se inicializa JavaScript, aparecerá un error (o el componente no funciona correctamente).Método alternativo: no active la validación del lado del cliente o las solicitudes. No active el ayudante de selector de fechas si el calendario árabe se está utilizando con el conversor.
Cuando se tiene como destino un tiempo de ejecución de servidor WebSphere®, asegúrese que el proyecto Web de WebSphere (Coexistencia) está seleccionado para el proyecto Web.
Método alternativo: seleccione la faceta en la segunda página del asistente Proyecto Web dinámico cuando cree el proyecto, o mediante la página Facetas de proyecto en el diálogo Propiedades del proyecto si el proyecto ya existe. Cuando se crea un proyecto Web destinado a un servidor WebSphere, si selecciona "Proyecto Faces" o "Proyecto Web dinámico con XDoclet" en la lista desplegable Configuraciones en la primera página del asistente de proyectos, la faceta de Web de WebSphere (coexistencia) no se seleccionará automáticamente. Puede continuar hasta la siguiente página del asistente para seleccionar esta faceta. Si selecciona "<personalizado>" en la lista Configuraciones, la faceta será seleccionada correctamente cuando se tenga como destino un tiempo de ejecución de WebSphere.
Cuando se utiliza
<hx:columnEx>
dentro de<hx:dataTableEx>
y el desplazamiento vertical está habilitado (scrollSize está establecido), si una o más de las columnas en la tabla tiene su ancho establecido como un ancho basado en porcentaje, en la tabla generada los encabezados y el contenido de las columnas puede que no estén alineados entre sí si el navegador interpreta el código doctype de la página como W3C estándar (en lugar de W3C Transitional). Por ejemplo, esto se sucederá si doctype incluye una declaraciónloose.dtd
.
Método alternativo: haga que los anchos de las columnas sean fijos (no basados en porcentajes) o bien asegúrese de que doctype se resuelve en un doctype de tipotransitional
(por ejemplo, elimine la declaración loose.dtd).
En
<hx:panelDialog>
, si el posicionamiento (ya sea vertical u horizontal) está establecido enrelative
y el código utilizado como base para el posicionamiento (el código respecto al cual se posiciona el diálogo) está en una página que está desplazada de manera que el código se está visualizando y la página no está desplazada hasta la parte superior, cuando se muestra el diálogo, es posible que se posicione de forma incorrecta (generalmente se posicionará demasiado en la parte superior o demasiado a la izquierda).Método temporal: si necesita utilizar el posicionamiento relativo, asegúrese de que el código base esté cerca de la parte superior de la página. Como alternativa, utilice uno de los otros tipos de posicionamiento.
Si una tabla de datos (
<h:dataTable>
o<hx:dataTableEx>
) se encuentra en un panel habilitado para AJAX y tiene habilitada la selección de filas (<hx:inputRowSelect>
está incluido en la tabla), los recuadros de selección en la selección no funcionará correctamente cuando la tabla vuelva a ser captada mediante AJAX. Esto funcionará correctamente (sólo) la primera vez que se genere.Método alternativo: no hay método alternativo en la actualidad para este problema. No ponga la tabla en un panel habilitado para AJAX.
Es posible que <hx:ajaxExternalRequest>
no funcione correctamente en Internet Explorer (IE) si el atributo source utilizado para especificar el ID del panel que desea recuperar en el panel de destino difiere del ID del panel al que se ha adjuntado<hx:ajaxExternalRequest>
en la página de origen. Por ejemplo,<hx:panel id="panel1"><hx:ajaxExternalRequest source="panel999" /><hx:panel>
. El problema sólo se produce en IE y sólo ocurre si el panel de destino es una cuadrícula, recuadro o diseño (un panel que se genera como una tabla HTML).Método alternativo: asegúrese de que los ID son los mismos o envuelva el panel de destino utilizando un elemento panelGroup.
El atributo
inProgresss
de<hx:ajaxRefreshRequest>
,<hx:ajaxRefreshSubmit>
,<hx:ajaxExternalRequest>
y<hx:inputHelperTypeahead>
no funciona. Establecer un valor en este atributo no tiene efecto alguno. Para asegurar la compatibilidad con futuros releases, no establezca el valor.
Cuando se adjunta
<hx:inputHelperTypeahead>
a un campo de entrada, si se especifica un carácter de espacio y/o caracteres de puntuación como un símbolo & y porcentaje en el campo, la lista de sugerencias que se construyen no incluirá ninguna de las "coincidencias" que incluyan dichos caracteres. Por ejemplo, si un usuario escribe %, no se devolverá ninguna coincidencia incluso si hay palabras en el "diccionario" en uso que comiencen por %.
Un cambio en el comportamiento de algunos atributos DOM de HTML a partir de la versión 1.5.0.8 de Firefox pueden resultar en que no se posicione correctamente un elemento
panelDialog
cuando se dibuja en Firefox. El problema se produce con mayor frecuencia cuando un diálogo se posiciona de forma relativa, pero puede producirse también cuando el tamaño del contenido del cuerpo es "menor que" la altura de la ventana del navegador (es decir, cuando la página no se desplaza verticalmente).Método alternativo: si añade contenido al cuerpo (incluso un espacio en blanco como <div> con la altura establecida) para que el desplazamiento vertical siempre esté en la página es posible que se solucione este problema (esto depende de las dimensiones exactas de la ventana del navegador y de su contenido).
<hx:pagerDeluxe>
no genera el código HTML correcto si styleClass está establecido en un valor distinto de la clasepagerDeluxe
predeterminada. Los botones en la página siempre serán generados con nombres de clase que utilicen el nombre de clase predeterminado en ellos.Método alternativo:
- No cambien el nombre de clase a un nombre distinto de pagerDeluxe.
- Ajuste el CSS utilizado para tener en cuenta los nombres de clase generados en los botones si se utiliza un nombre de clase distinto.