© Copyright International Business Machines Corporation 2006. Todos direitos reservados. Direitos Restritos para Usuários do Governo dos Estados Unidos - Uso, duplicação e divulgação restritos pelo documento GSA ADP Schedule Contract com a IBM® Corporation.
O seguinte foi reprovado e não é recomendado para uso:
- Dados de Cliente e ferramentas associadas (como a visualização Dados de Cliente)
- Componentes do Faces Client
<odc:dataGrid>
(Grade de Dados)<odc:webService>
(Serviço da Web)<odc:clientData>
<odc:clientBinder>
A Árvore
<odc:tree>
e o Gráfico<odc:graphDraw>
foram ativados para utilizar os Dados do Servidor.
Se você importar um aplicativo JSF anterior à V7 sem migrar o JARS JSF e continuar desenvolvendo o aplicativo, as novas tags da V7 não serão inclusas nos JARs do projeto e não estarão disponíveis no tempo de execução. Certifique-se de migrar o JARS anterior à V7.
A tag
<odc:treeNodeAttr>
do controle de Árvore utiliza valores diferentes para seu atributo className quando está ligada a dados SDO versus dados WDO. Depois de migrar um projeto de um servidor que utiliza WDO (como o WebSphere® Application Server 5.1) para um que utilize SDO (como o WebSphere Application Server 6.1), a forma mais fácil de corrigir isso é excluir e recriar quaisquer controles de Árvore.
Na v6.0, se um
<hx:commandExButton>
tivesse o tipo configurado como Submit e tivesse um rótulo e apenas uma imagem de plano de fundo simples (por exemplovalue="submit" image="button.gif"
), apenas a imagem era renderizada (não a imagem e o rótulo). Esse problema foi corrigido na v7.0. A correção significa que os botões que tenham um rótulo e uma imagem de plano de fundo simples serão renderizados diferentemente ao utilizar a v7.0 do que eram na v6.0.Da mesma forma, se um
<hx:commandExButton>
tivesse o tipo configurado comoReset
e tivesse uma imagem de plano de fundo simples (ou uma imagem de plano de fundo e um rótulo), apenas a imagem seria renderizada e o botão era tratado como um botão de envio (o tipo do botão era ignorado). Esse problema foi corrigido na v7.0. A correção significa que os botões marcados com o tipo configurado comoReset
agora irão reconfigurar a página, em vez de enviá-la.
Os atributos da tag
<jspPanel>
style
estyleClass
não estão mais disponíveis. Os atributos não são utilizados para renderização do componente do painel do JSP.Se você importar um aplicativo JSF criado em uma versão anterior deste produto, as tags
<jspPanel>
exibirão erros. Para resolver os erros, remova os atributosstyle
estyleClass
de todas as tags<jspPanel>
do projeto, editando a origem da JSP na visualização Origem.
Se você importar projetos no espaço de trabalho que foram criados utilizando uma versão anterior do produto, poderá ver um pop-up de diálogo indicando que o suporte a Faces foi instalado, mas nenhum tempo de execução de destino foi selecionado para o projeto. Em alguns casos, esse aviso não está correto e um tempo de execução estará corretamente definido após a conclusão do processo de migração. Para verificar se um tempo de execução está configurado, clique com o botão direito do mouse em Projeto > Propriedades e selecione Tempos de Execução de Destino. Se aparecer uma caixa de opções ao lado de algum servidor definido, nenhuma ação adicional será necessária; caso contrário selecione um dos servidores.
Nota: Esta solução alternativa não é necessária onde modelos de dados de cliente forem criados a partir do mesmo nó de dados da página ou nós de dados da página de mesmo nome.
Na v7.0, quando houver vários modelos de dados de cliente na página, criados a partir das mesmas classes de bean, um segundo arquivo ecore e emap será erroneamente criado para o segundo modelo após a geração (ou regeneração). De acordo com o guia de migração, ao migrar projetos de dados de cliente, os modelos de dados de cliente devem ser regenerados, portanto isso pode impactar projetos migrados com páginas que contenham mais de um modelo de dados de cliente. Um cenário simples é apresentado a seguir:
- Crie dois elementos de dados de página com base no bean java.util.Date, por exemplo myDate1 e myDate2.
- Para cada um dos elementos de dados de página, crie um modelo de Dados de cliente com o mesmo nome na ordem: myDate1 e, em seguida, myDate2.
Solução alternativa: Para fazer com que uma página funcione com os dois modelos, exclua myDate2.ecore e myDate2.emap do pacote com.ibm.dynwdo4jsmediators e as entradas correspondentes no arquivo OdysseyBrowserFramework.properties.
Os Dados de Cliente geram uma grande quantidade de JavaScript™ para uma página. Nos releases anteriores, o JavaScript não estava codificado. Isso significava que se você estivesse utilizando Dados de Cliente em vários portlets, utilizando a mesma origem de dados de página, a saída do JavaScript para a página seria a mesma para todos os portlets.
Esse comportamento, onde dois portlets são ligados a Dados de Cliente, poderia aparentar ligação ao mesmo objeto de Dados de Cliente (pois a segunda seção do JavaScript sobrescreverá a primeira). Por sua vez, isso permite que os dois portlets interajam, onde uma alteração em um deles seria representada em ambos.
Isso é problemático se você deseja ter vários portlets em uma página que utilizam os Dados de Cliente e funcionam de forma independente uns dos outros. Ocorrem erros de JavaScript quando existem dois portlets que usam Dados de Cliente na mesma página com diferentes origens de Dados da Página. Isso também pode fazer com que um dos portlets não seja renderizado.
Para corrigir esses problemas e permitir que os Portlets de Dados de Cliente sejam executados sobre WSRP, as variáveis JavaScript de Dados de Cliente devem ser codificadas, de forma que sejam exclusivas para cada portlet. Isso permite que as seções JavaScript de Dados de Cliente funcionem de forma independente umas das outras.
Na V7.0, todos os dados de cliente serão codificados.
Se você deseja compartilhar Dados de Cliente entre portlets em uma página, precisará atualizar web.xml com os seguintes parâmetros de contexto:
<context-param>
<param-name>com.ibm.faces.ENCODE_DATA</param-name>
<param-value>false</param-value>
<description></description>
</context-param>Configurando <param-value> como false, você está removendo a codificação dos Dados de Cliente.
Utilizando o parâmetro Encode_Data e seu efeito nos componentes Árvore de Dados e Gráfico utilizando Dados de Página
A Árvore de Dados e Gráfico utilizam dados de página colocando um objeto de dados XML na página. Os Dados da Página para a Árvore de Dados e Gráfico é bastante vinculada aos Dados de Cliente para esses componentes. Por padrão, esses dados são codificados. Se você configurar o <context-param> mostrado a seguir em seu arquivo web.xml, que normalmente é utilizado para remover a codificação de Dados de Cliente, isso também removerá a codificação de Dados da Página para a Árvore de Dados e Gráfico. Nenhum outro componente que utiliza os dados da página será afetado. Deixar os dados da página sem codificação, o que significa ter dois portlets em uma página, onde ambos contêm um gráfico ou uma Árvore de Dados, pode causar problemas. Esses erros incluem erros de JavaScript e/ou na exibição incorreta de um dos portlets.
Para que os Dados de Cliente codifiquem esses dados, permitindo que dois portlets em uma página sejam executados de forma independente um do outro e ativar o suporte a WSRP, você precisará remover o seguinte <context-param> de web.xml ou configurar <param-value> como true:
<context-param>
<param-name>com.ibm.faces.ENCODE_DATA</param-name>
<param-value>true</param-value>
<description></description>
</context-param>
Isto é colocado no início da página:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
Isso faz com que os navegadores da Web vão para o modo padrão. No modo padrão, os elementos
HTML
ebody
encaixam em seu conteúdo em vez de preencher a janela, como ocorre no modo quirks (o modo HTML padrão).Quando um painel com guias é colocado na página por si próprio com sua altura configurada como uma porcentagem, isso causará problemas de exibição com a altura da área de janela.
Para corrigir isso, coloque o painel com guias em um contêiner que tenha uma altura configurada ou altere o tipo de documento no início da página para:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
Há problemas de exibição com guias no modo padrão quando o tipo de documento está configurado como:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
Isso é corrigido alterando-se o tipo de documento para:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
A tag
<hx:convertDateTime>
não gera JavaScript correto quando o tipo de calendário está configurado como árabe. Como resultado, a validação do lado do cliente, o aviso de entrada, o selecionador de data auxiliar e o minicalendário não funcionam corretamente. Quando o JavaScript gerado for inicializado, um erro será exibido (ou o componente não funcionará corretamente).Solução alternativa: Não ligue a validação do lado do cliente ou o aviso. Não ligue o selecionador de data auxiliar se o calendário árabe for utilizado com o conversor.
Ao definir o destino de um tempo de execução do servidor do WebSphere®, assegure-se de que o aspecto de projeto WebSphere Web (coexistência) esteja selecionado para seu projeto da Web.
Solução alternativa: Selecione o aspecto na segunda página do assistente Projeto da Web Dinâmico ao criar o projeto ou utilizando a página Aspectos do Projeto do diálogo Propriedades do projeto se o projeto já existir. Ao criar um projeto da Web destinado a um servidor do WebSphere, se você selecionar "Projeto Faces" ou "Projeto da Web Dinâmico com XDoclet" na lista drop-down Configurações na primeira página do assistente do projeto, o aspecto WebSphere Web (coexistência) não será selecionado automaticamente. É possível continuar com a próxima página do assistente para selecionar esse aspecto. Se você selecionar "<customizado>" na lista Configurações, o aspecto será selecionado corretamente ao definir o destino para um tempo de execução do WebSphere.
Ao utilizar
<hx:columnEx>
em um<hx:dataTableEx>
e a rolagem vertical estiver ativada (scrollSize estiver configurado), se uma ou mais das colunas na tabela tiver sua largura configurada para ser uma largura com base em porcentagem, na tabela renderizada, os cabeçalhos de coluna e o conteúdo das colunas poderão não ficar alinhados entre si se o tipo de documento da página for interpretado pelo navegador como sendo o padrão do W3C (versus transicional do W3C). Por exemplo, isso ocorrerá se o tipo de documento incluir uma declaraçãoloose.dtd
.
Solução alternativa: Torne as larguras de coluna fixas (não baseadas em porcentagem) ou certifique-se de que o tipo de documento seja resolvido para um tipo de documentotransicional
(por exemplo, remova a declaração loose.dtd).
Em um
<hx:panelDialog>
, se o posicionamento (horizontal ou vertical) estiver configurado comorelative
e a tag utilizada como a base para o posicionamento (a tag em relação à qual o diálogo é posicionado) estiver em uma página que é rolada, de forma que a tag está sendo exibida e a página não é rolada para o início, quando o diálogo for exibido, ele poderá ser posicionado incorretamente (normalmente posicionado muito no início ou muito à esquerda).Solução alternativa: Se o posicionamento relativo for necessário, assegure-se de que a tag tag base esteja próxima ao início da página. Alternativamente, utilize um dos outros tipos de posicionamento.
Se uma tabela de dados (
<h:dataTable>
ou<hx:dataTableEx>
) estiver em um painel que esteja ativado para AJAX e tenha a seleção de linhas ativada (<hx:inputRowSelect>
está incluído na tabela), as caixas de opções na coluna de seleção não funcionarão corretamente quando a tabela for buscada novamente utilizando AJAX. Ela funcionará corretamente na primeira vez (apenas) em que for renderizada.Solução alternativa: Atualmente não existe solução alternativa para esse problema. Não coloque a tabela em um painel ativado para AJAX.
<hx:ajaxExternalRequest>
pode não funcionar corretamente no Internet Explorer (IE) se o atributo source for utilizado para especificar o ID do painel a ser recuperado na página de destino e diferir do ID do painel ao qual<hx:ajaxExternalRequest>
está conectado na página de origem. Por exemplo,<hx:panel id="panel1"><hx:ajaxExternalRequest source="panel999" /><hx:panel>
. O problema ocorre apenas no IE e somente se o painel de destino for uma grade, caixa ou layout (um painel que é renderizado como uma tabela HTML).Solução alternativa: Certifique-se de que os IDs sejam os mesmos ou agrupe o painel de destino em um panelGroup.
O atributo
inProgresss
para<hx:ajaxRefreshRequest>
,<hx:ajaxRefreshSubmit>
,<hx:ajaxExternalRequest>
e<hx:inputHelperTypeahead>
não funciona. Configurar um valor nesse atributo não tem efeito. Para assegurar compatibilidade com releases futuros, não configure o valor.
Quando
<hx:inputHelperTypeahead>
está anexado a um campo de entrada, se um caractere de espaço e/ou caractere de pontuação como e comercial ou porcentagem forem digitados no campo, a lista de sugestões que são construídas não incluirá nenhuma "correspondência" que inclua esses caracteres. Por exemplo, se um usuário digitar %, nenhuma correspondência será retornada, mesmo se existirem palavras no "dicionário" em uso que iniciem com %.
Uma alteração no comportamento de alguns atributos HTML DOM a partir do Firefox versão 1.5.0.8 pode resultar no posicionamento incorreto de um
panelDialog
quando renderizado no Firefox. O problema ocorre com mais freqüência quando um diálogo é posicionado de forma relativa, mas pode ocorrer em outros casos em que o tamanho do conteúdo do corpo é "menor que" a altura da janela do navegador (isto é, quando a página não rola verticalmente).Solução alternativa: A inclusão de conteúdo no corpo (mesmo espaços em branco como um <div> com a altura configurada) de forma que a barra de rolagem vertical fique sempre ativa na página pode solucionar o problema (isso depende das dimensões exatas da janela do navegador e do conteúdo).
<hx:pagerDeluxe>
não renderiza a marcação HTML correta se styleClass estiver configurado como algo diferente da classe padrão,pagerDeluxe
. Os botões no pager serão sempre renderizados com nomes de classe que utilizam o nome de classe padrão neles.Solução alternativa:
- Não altere o nome de classe para algo diferente de pagerDeluxe.
- Ajuste a CSS utilizada para levar em conta os nomes de classe que são renderizados nos botões se um nome de classe diferente for utilizado.