Migrando Recursos JavaServer Faces com Componentes Faces Client

Se você criou projetos no WebSphere Studio V5.1.x contendo Componentes Faces Client nos JSPs (JavaServer Pages) do JavaServer Faces, será necessário migrar os recursos do tempo de execução dos Componentes Faces Client para os níveis mais recentes.

Depois de abrir um projeto na V6.0 contendo JSPs do JavaServer Faces com Componentes Faces Client criados no WebSphere Studio V5.1.x, você deve fazer o seguinte para migrar os recursos do tempo de execução dos Componentes Faces Client:
  1. Crie um novo arquivo JSP e, para o modelo, selecione Básico com cache de dados do lado cliente. Esse JSP é necessário apenas temporariamente para que o Rational Web Developer migre todos os arquivos JAR (Java archive) do sistema para os níveis mais recentes.
  2. Você será avisado que pode migrar os recursos do tempo de execução do projeto para os níveis mais recentes. Selecione Sim para concluir o processo de migração. Importante: Se você selecionar Não ou cancelar a caixa de diálogo, os Componentes Faces Client de seu projeto não serão migrados para os níveis mais recentes e você não será avisado novamente, causando vários problemas sérios entre as novas ferramentas e os arquivos JAR antigos do tempo de execução.
  3. Depois de criar o novo arquivo JSP, você pode excluí-lo do projeto.
  4. Selecione qualquer objeto de dados na área Dados de Cliente, clique no botão direito do mouse e selecione Configurar. Na guia Avançado, selecione Regenerar Tudo, que regenerará todos os seus mediadores.
    Nota: Não utilize o botão Regenerar a partir dos dados do lado do servidor. Você deve utilizar Regenerar Tudo.
  5. Há elementos do esquema WDO (WebSphere Data Objects) na versão 5.12 que não são mais utilizados na versão 6.0. As classes de mediadores para esses elementos não serão regeneradas e continuarão tendo erros de compilação. Esses mediadores terão a convenção de nomenclatura *_DataGraphSchema_wdo4js_*.java. Exclua essas classes de mediadores de seu projeto para evitar os erros de compilação.
Se você estiver trabalhando na plataforma Linux ou se estiver utilizando um código do idioma não-inglês: Antes de seguir as etapas descritas anteriormente para migrar seus projetos criados no WebSphere Studio V5.1.x contendo Componentes Faces Client em JSPs do JavaServer Faces, você poderá receber a seguinte mensagem de erro quando os projetos forem carregados na V6.0:
O projeto não pode ser construído porque o <nome_da_classe>.java não pôde ser lido.
Os arquivos não puderam ser lidos porque as classes de mediadores dos Dados de Cliente no projeto V5.1.x podem conter caracteres especiais que não foram codificados, ao passo que as classes de mediadores no Rational Web Developer V6.0 codificam esses caracteres. Essas mensagens de erro param assim que você regenera os Dados de Cliente, seguindo as etapas descritas anteriormente. Entretanto, antes de seguir as etapas para migrar o projeto contendo Componentes Faces Client, você deve primeiro excluir os arquivos de mediadores dos Dados de Cliente do projeto carregado na V6.0 para que seu espaço de trabalho possa ser construído. Para excluir os arquivos de mediadores dos Dados de Cliente:
  1. Exclua de seu projeto todos os pacotes de classes de mediadores dos Dados de Cliente que tenham a convenção de nomenclatura com.ibm.dynwdo4jsmediators.<nome-dos-dados-de-cliente>.
  2. NÃO exclua o pacote denominado com.ibm.dynwdo4jsmediators. Esse pacote contém metadados (arquivos ecore e emap) para os Dados de Cliente em seu projeto que serão utilizados para regenerar os mediadores.
  3. Após a exclusão dos pacotes de mediadores, o projeto será agora construído. Agora você pode concluir as etapas de migração descritas anteriormente.

Em alguns casos, você pode receber uma mensagem falha na geração do mediador. Para corrigir esse problema, edite o arquivo OdysseyBrowserFramework.properties e exclua as entradas para as propriedades EMAP_FILES e ECORE_FILES e tente novamente.

Nota: Podem ocorrer problemas ao alterar o servidor de destino de um projeto contendo Componentes Faces Client do WebSphere Application Server V5.1 para V6.0.
Há dois problemas que podem ocorrer ao alterar o servidor de destino de um projeto contendo Componentes Faces Client do WebSphere Application Server V5.1 para V6.0:
  • As classes de mediadores dos Dados de Cliente que já foram geradas não serão mais compiladas. Elas precisam ser regeneradas em um JSP por vez. Isso é feito da seguinte forma:
    1. Abra o arquivo OdysseyBrowserFramework.properties localizado na pasta de origem Java da raiz. Salve o conteúdo para uso futuro.
    2. No arquivo OdysseyBrowserFramework.properties, para cada JSP contendo Dados Faces Client em seu projeto, localize as entradas <nome-dos-dados-de-cliente>.ecore e <nome-dos-dados-de-cliente>.emap para as propriedades EMAP_FILES e ECORE_FILES.
    3. Mantenha apenas as entradas correspondentes aos Dados de Cliente em seu JSP e exclua todas as outras entradas.
      Por exemplo, se a página atual tiver Dados de Cliente denominados ACCOUNT e seu arquivo de propriedades tiver uma entrada como:
      EMAP_FILES=com\\ibm\\dynwdo4jsmediators/account.emap com\\ibm\\dynwdo4jsmediators/orders.emap
      você deverá excluir com\\ibm\\dynwdo4jsmediators/orders.emap da entrada. A entrada seria agora semelhante a esta:
      EMAP_FILES=com\\ibm\\dynwdo4jsmediators/account.emap
    4. Salve o arquivo de propriedades.
    5. Clique com o botão direito do mouse nos Dados de Cliente em seu JSP e selecione Configurar.
    6. Selecione a guia Avançado. Clique no botão Regenerar Tudo. Isso regenerará todos os artefatos necessários para todos os Dados de Cliente no JSP atual.
    7. Repita essas etapas para cada JSP contendo Dados de Cliente em seu projeto.

    Depois de regenerar as classes de mediadores dos Dados de Cliente para os JSPs em seu projeto, ainda permanecerão algumas classes de mediadores que não serão compiladas. Estes são mediadores para elementos do esquema não mais utilizados nos SDOs (Service Data Objects) na V6.0. Esses mediadores terão a convenção de nomenclatura *_DataGraphSchema_wdo4js_*.java e *_RootDataObject_wdo4js_*.java. Exclua essas classes de mediadores de seu projeto para evitar os erros de compilação.

    Depois que a migração for concluída com êxito, restaure o conteúdo original do arquivo OdysseyBrowserFramework.properties.

  • Os Componentes Faces Client da Visualização em Árvore ligados aos WDOs falham ao executar no servidor após a alteração do servidor de destino do projeto para o WebSphere Application Server V6.0.
    A solução alternativa para isso é modificar a visualização de origem de seu JSP para alterar todas as tags className para utilizar a classe DataObject do SDO em vez da classe DataObject do WDO. Por exemplo, para um WDO denominado account:
    1. Para o objeto raiz, altere a tag className de className="com.ibm.etools.wdo.DataObject(DynWDO`account`RootDataObject)" para className="commonj.sdo.DataObject(DynWDO`account`DataGraphRoot)".
    2. Para todos os nós-filho, altere a tag className de className="com.ibm.etools.wdo.DataObject(DynWDO`account`ACCOUNT)" para className="commonj.sdo.DataObject(DynWDO`account`ACCOUNT)", em que ACCOUNT é o nome do nó de dados.
Fazendo upgrade para processadores e rotinas de tratamento Diff automatizados: Os processadores e rotinas de tratamento Diff são agora gerados automaticamente. Se você gravou rotinas de tratamento e processadores Diff para seus Componentes Faces Client no WebSphere Studio V5.1.x, é recomendável descartar esse código e utilizar os processadores e rotinas de tratamento gerados automaticamente. Para fazer isso, é necessário executar as etapas a seguir:
  1. Gere os novos processadores e rotinas de tratamento Diff. Para isso, em cada Objeto de Dados de Cliente de seu projeto, você deve fazer o seguinte:
    1. Selecione o Objeto de Dados de Cliente, clique com o botão direito do mouse e selecione Configurar.
    2. Na guia Avançado, selecione Regenerar Tudo.
  2. Remova o código gravado para chamar seus processadores e rotinas de tratamento Diff, pois os processadores e rotinas de tratamento gerados são chamados automaticamente. Um exemplo típico de onde esse código foi utilizado seria no evento Comando para o componente Botão de Comando. O exemplo a seguir mostra como seria o código:
    String Diff = getClientData1().getDiffStr();
    if (DiffProcessor.Synch(getRoot(), Diff) == true)
     return "";
    return "failure";
  3. Remova de seu projeto os arquivos correspondentes aos processadores e rotinas de tratamento personalizados antigos que você criou.
Mantendo processadores e rotinas de tratamento Diff personalizados gravados na V5.1.x: Embora isso não seja recomendado, se você decidir que precisa manter os processadores e rotinas de tratamento Diff personalizados da V5.1.x, será necessário modificá-los para que funcionem na V6.0, uma vez que a interface DiffHandler e a classe DiffInfo foram alteradas.
  • A interface DiffHandler foi alterada da seguinte forma:
    • O método handle agora emite Exception, além de DiffException.
    • O novo método find é utilizado pela estrutura para localizar objetos.
    • O novo método getId é utilizado para depuração e permite que a estrutura imprima o valor de um objeto.

    Os métodos find e getId são utilizados internamente pelos DiffHandlers gerados. Para seus DiffHandlers personalizados, você pode implementar métodos vazios simplesmente para obter conformidade com a interface. Esses métodos não serão chamados pela estrutura.

    A interface DiffHandler é agora:
    public interface DiffHandler
     {
       public void   handle(DiffInfo Diff) throws DiffException, Exception;
       public Object find  (DiffInfo Diff) throws DiffException, Exception;
       public String getId (DiffInfo Diff, boolean Original);
     }
  • A classe DiffInfo foi alterada da seguinte forma:
    • O método ArrayList getAncestors() foi substituído pelo método DiffInfo getParent(), que oferece uma maneira mais fácil de acessar as informações de cada objeto na árvore de ascendentes de um modo recursivo.
    • Os métodos getCurrent() e getOriginal() agora retornam um objeto DataObject em vez de um objeto EObject. Não é obrigatório alterar o código para utilizar o objeto DataObject. Entretanto, a interface DataObject é muito mais fácil e mais intuitiva para ser utilizada que EObject. Você pode converter facilmente um objeto DataObject em um objeto EObject para o código legado.
    • Um novo método String getPropertyName() foi incluído para identificar o nome da propriedade à qual esse objeto se aplica. Isso será importante se, por exemplo, uma determinada classe tiver duas propriedades do mesmo tipo. Anteriormente na classe DiffInfo, o código não conseguiria diferenciar entre as duas propriedades.
    A classe DiffInfo é agora:
    public class DiffInfo
     {
       public char       getCrud()
       public DataObject getCurrent()
       public String     getEClassName()
       public DataObject getOriginal()
       public String     getPropertyName()
       public DiffInfo   getParent()
     }
    Nota: A classe DiffInfo não é mais suportada para utilização pública porque agora os processadores e rotinas de tratamento Diff são gerados automaticamente. Manter suas rotinas de tratamento antigas é uma solução apenas temporária e é bastante recomendável que as rotinas de tratamento automatizadas sejam utilizadas.
Alterações nos Componentes Faces Client na V6.0:
  • Suporte para o WebSphere Application Server V6.0.
  • Suporte para o SDO (Service Data Objects) no WebSphere Application Server V6.0.
  • Os dados EGL são agora suportados como dados de cliente.
  • Os processadores e rotinas de tratamento Diff são gerados automaticamente.
  • Há novos eventos para os seguintes Componentes do Cliente:
    • TabbedPanel: onInitialPageShow
    • Árvore: onNodeExpand, onNodeCollapse, onExpand, onCollapse
    • DataGrid: onPage, onSort, onFilter
Tarefas relacionadas
Migrando Recursos Faces em um Projeto de Portlet
Termos de Utilização | Feedback
(C) Copyright IBM Corporation 2000, 2005. Todos os Direitos Reservados.